System Design Interview Questions
System design interviews are open-ended by nature — there's rarely a single 'correct' answer — but the questions asked tend to fall into recognizable families, and interviewers are consistently evaluating the same underlying skills regardless of the specific prompt: can the candidate clarify ambiguous requirements, estimate scale realistically, propose a coherent high-level architecture, identify the hard tradeoffs, and go deep on at least one or two components when pushed. Knowing the common question archetypes helps you recognize which patterns (caching, sharding, fan-out, consistency) are likely to be central before you've even finished reading the prompt.
Cricket analogy: A system design interview is like a captain's pre-match huddle — there's no single correct game plan, but selectors are watching whether you clarify pitch conditions, estimate a realistic target score, propose a coherent batting order, weigh tradeoffs, and can go deep when questioned about one specific bowling change.
Common question archetypes
Storage-and-retrieval systems (design a URL shortener, a key-value store, a distributed file store like Dropbox) center on data modeling, partitioning, and indexing. Real-time/messaging systems (design a chat app, a notification system, a live-comments feature) center on connection management, delivery guarantees, and ordering. Feed/ranking systems (design a news feed, a trending-topics service, a recommendation system) center on fan-out strategy and how ranking interacts with data freshness. Rate-limited or resource-constrained systems (design a rate limiter, a ticket-booking system with limited inventory, a parking garage system) center on concurrency control and preventing overselling/overuse. Search-and-discovery systems (design a search autocomplete, a nearby-search/Yelp-like service) center on indexing structures (tries, geospatial indexes) and query latency.
Cricket analogy: Storage-and-retrieval questions are like designing a stadium's archive of every ball bowled; real-time/messaging questions are like a live ball-by-ball commentary feed; feed/ranking is like a trending-players leaderboard; rate-limited is like a ticket-booking system with limited stadium seats; search is like a player-stats lookup tool.
What interviewers are actually scoring
Beyond the specific architecture proposed, strong candidates are usually differentiated on: whether they ask clarifying questions before diving in (scale, read/write ratio, consistency requirements, latency targets) rather than assuming; whether their capacity estimates are roughly sane (back-of-envelope QPS, storage growth, bandwidth) even if not perfectly precise; whether they can explain *why* they chose one option over an alternative (e.g., SQL vs NoSQL, push vs pull) rather than just naming a technology; and whether they can adapt when the interviewer changes a constraint mid-interview (e.g., 'now assume 100x the traffic' or 'now assume strong consistency is required') — this adaptability under a changed constraint is often the single most differentiating signal in the interview.
Cricket analogy: A strong captain asks about pitch and weather before setting a field, makes a roughly sane run-chase estimate, explains why they chose spin over pace, and adapts smoothly when the umpire suddenly announces rain reducing the match to a 20-over chase.
Representative prompts by category:
Storage & retrieval:
- Design a URL shortener
- Design a distributed key-value store
- Design a file storage/sync service (Dropbox/Google Drive)
Real-time / messaging:
- Design a chat application
- Design a notification system
- Design a live comment/reaction stream for a video
Feed & ranking:
- Design a news feed
- Design a trending topics / hashtags service
- Design a recommendation system
Resource-constrained / concurrency:
- Design a rate limiter
- Design a ticket booking / seat reservation system
- Design a distributed lock service
Search & discovery:
- Design a search autocomplete / typeahead
- Design a nearby-search service (Yelp/Uber-like)
- Design a web crawlerA useful structural habit: spend the first 5-10 minutes of any interview explicitly stating assumptions and estimates out loud ('I'll assume 10M daily active users, a 20:1 read:write ratio, and that eventual consistency is acceptable for this feature') before drawing a single box. This single habit — visible in almost every strong interview performance — signals structured thinking more than any specific architecture choice does.
A common failure mode is jumping straight to naming trendy technologies ('we'll use Kafka and Kubernetes and a microservices architecture') without first establishing what problem those choices solve for this specific prompt. Interviewers frequently probe with 'why not just use a single SQL database here?' — if a candidate can't articulate the concrete requirement (throughput, availability, decoupling) that justifies the added complexity, it reads as name-dropping rather than design skill.
- System design questions cluster into recognizable archetypes: storage/retrieval, real-time/messaging, feed/ranking, resource-constrained, and search/discovery.
- Interviewers primarily evaluate clarifying questions, sane capacity estimation, justified tradeoffs, and adaptability to changed constraints — not a single 'correct' architecture.
- Stating explicit assumptions and estimates early signals structured thinking and is one of the most consistently observed traits of strong performances.
- Every proposed technology or pattern should be tied to a specific requirement it satisfies, not introduced by name alone.
- Being able to redesign under a changed constraint (10x scale, strong consistency required) mid-interview is one of the strongest differentiating signals.
- Depth matters as much as breadth — interviewers expect at least one or two components explored in real detail, not just a broad box diagram.
Practice what you learned
1. What do system design interviewers primarily evaluate, according to common interview archetypes?
2. Why is stating explicit assumptions and estimates early in the interview considered a strong habit?
3. What is the risk of naming technologies like Kafka or Kubernetes without justification during a system design interview?
4. Which category of system design question centers primarily on connection management, delivery guarantees, and ordering?
5. Why is a candidate's ability to redesign under a mid-interview constraint change (e.g., '10x the traffic') considered a strong differentiating signal?
Was this page helpful?
You May Also Like
The System Design Interview Approach
A structured framework for tackling open-ended system design interview questions, from requirement gathering through high-level design, deep dives, and trade-off discussion.
Designing a News Feed System
Explores how systems like Facebook or Twitter assemble a personalized, ranked feed at scale, contrasting fan-out-on-write and fan-out-on-read delivery models.
Common System Design Mistakes
A catalog of recurring architectural and interview mistakes — over-engineering, ignoring tradeoffs, false precision, and skipping requirements gathering — with how to avoid each.
System Design Quick Reference
A condensed cheat sheet mapping common system design problems, algorithms, and tradeoffs to when each applies — useful for rapid review before an interview.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics