System design interview questions

The complete guide to the system design interview archetype: what interviewers are actually testing, how to structure a strong answer, 20 real reported example questions, and the practice loop that makes you better at this pattern. Read it once, then run a session.

What interviewers are really testing

The interviewer isn't evaluating whether you can architect Twitter in 45 minutes—they know you can't. They're testing whether you can operate effectively in the ambiguous, constraint-driven environment where real systems are built. When a hiring manager watches you work through a system design problem, they're asking: "Will this person build something that works for our actual constraints, or will they over-engineer a solution that sounds impressive but ships six months late?" The question reveals whether you gather context before committing to solutions, whether you can identify what actually matters at different scales, and whether you'll drown the team in premature optimization or miss obvious bottlenecks until production melts down.

More specifically, interviewers are probing your judgment about trade-offs and your communication under uncertainty. A senior engineer who can't explain why they're choosing PostgreSQL over Cassandra for a particular access pattern—or who can't articulate what they're not optimizing for—is a risk. The decision itself matters less than the reasoning. Similarly, an architect who designs in silence and presents a finished diagram has demonstrated they'll disappear for two weeks and emerge with something nobody asked for. The collaborative back-and-forth during the interview simulates the design review meetings where you'll need to build consensus, and the interviewer is deciding whether you're someone they'd trust in that room.

Three mistakes that lose this question

• Jumping to architecture before establishing scale and requirements. You start drawing load balancers and cache layers within the first three minutes because you want to demonstrate you know these components exist. This signals you'll waste engineering resources building for scale you don't have, or worse, that you'll confidently implement the wrong thing because you didn't stop to understand what "high availability" means for this specific use case—99.9% and 99.999% uptime require completely different architectures.

• Treating every component as equally important instead of identifying the actual bottleneck. You spend equal time discussing the API gateway, the database, the cache, the message queue, and the CDN, giving each a surface-level mention. This reveals you can't distinguish between what matters and what doesn't, which in practice means you'll spend three sprints optimizing the login flow when the real problem is the search index, because you lack the judgment to know where the system will actually break.

• Describing technologies without explaining the trade-offs you're navigating. You say "we'll use Redis for caching" or "we'll shard the database" without articulating what you're giving up or what problem this specifically solves. This exposes that you're pattern-matching to solutions you've seen rather than reasoning from first principles, which means you'll cargo-cult architecture decisions and won't be able to adapt when the context changes or debug when things go wrong.

The frame strong candidates use

The strongest candidates treat system design as a negotiation about constraints, not a demonstration of components they've memorized. They explicitly state their assumptions and invite correction: "I'm assuming we need to handle 10,000 writes per second and reads are 100x that—does that match your expectation?" This isn't weakness; it's showing you understand that the "right" architecture doesn't exist in a vacuum. When you quantify early and often, you're demonstrating the discipline that prevents real projects from scope-creeping into distributed systems nightmares. The candidates who get offers are comfortable saying "at this scale, we don't need that complexity yet" just as confidently as they describe how to handle the next two orders of magnitude.

The deep-dive portion is where good candidates separate themselves by showing depth over breadth. When you identify that the write-heavy analytics pipeline is the actual bottleneck and spend ten minutes exploring batch versus stream processing trade-offs, partitioning strategies, and consistency requirements, you're proving you can go from 30,000 feet to the ground without losing coherence. Weak candidates treat the deep-dive as "mention more technologies"—they'll add Kafka and Spark to the diagram without explaining why. Strong candidates pick one real problem, acknowledge they're deliberately leaving other areas shallow, and demonstrate they can hold a technical conversation at the level where actual implementation decisions get made. The interviewer is imagining you in a design review, and they need to see you can go deep enough that the team leaves with clear direction, not just a whiteboard full of boxes.

Quick reference

Engineering system design — design a URL shortener, newsfeed, distributed queue.

The structure of a strong answer

Strong system design answers follow a consistent shape. You can deliver any specific story over this skeleton — and the skeleton is what interviewers are pattern-matching against, even if they don't say so.

20 real system design questions from interviews

Drawn from our verified bank — sourced from candidate-reported interviews, paraphrased into archetype form, quality-scored before publication.

1. Your encoding farm has 2000 machines encoding chunks simultaneously. One machine fails mid encoding. 1999 chunks complete successfully but chunk 847 is lost. The entire movie is incomplete. At scale machine failures happen constantly. How do you make the pipeline fault tolerant?
2. Implement a high-throughput web crawler with thread safety and rate limiting
3. A 4K HDR movie is 100GB. A user has a 50 Mbps connection. Downloading 100GB takes 4.4 hours. But Netflix starts playing in under 3 seconds. How is this physically possible?
4. Millions of stop loss orders all trigger simultaneously when a price drops sharply. Each converts to a market order instantly flooding the matching engine. How do you handle this?
5. Phone GPS has 5 to 15 meter accuracy. A stationary phone looks identical to a traffic jam. A phone moving slowly through a school zone looks like congestion. With billions of noisy GPS points how do you ensure traffic computation reflects actual road conditions?
6. You have pre-rendered static tiles cached on CDN. Traffic conditions change every few minutes. Re-rendering and re-caching billions of tiles every few minutes is too slow and expensive. How do you overlay dynamic traffic data on static tiles?
7. Build a BFS web crawler with URL deduplication and boundary constraints
8. A raw master file could be 1TB of uncompressed footage. Netflix needs to create thousands of chunks at 5 quality levels each. Encoding a 3 hour movie sequentially on one machine could take days. Netflix adds thousands of new titles every year. How do you process them fast enough?
9. Dijkstra exploring all roads equally for a Mumbai to Delhi query wastes enormous computation on tiny side streets that could never be part of the optimal route. How do you make routing dramatically faster?
10. Implement LRU cache with O(1) operations using hash map and linked list
11. The Order Book lives in memory on one machine. A crash loses every pending order worth billions of dollars. But distributing across machines adds milliseconds of latency destroying microsecond matching. How do you make a single machine Order Book fault tolerant?
12. Find shortest transformation steps in a word graph using BFS
13. Netflix stores the same chunk at 5 different quality levels. Why — and who decides which quality to request?
14. Every trade must settle atomically — buyer gets shares and seller gets money together or neither happens. A crash between the two steps leaves one party with nothing. How do you guarantee atomicity?
15. 500 million Android phones with Google Maps open send GPS location every few seconds. Google must process this to detect traffic patterns in near real time. How do you design the pipeline that converts billions of location updates into real time traffic conditions?
16. User searches Italian restaurants near me. Results must consider both text relevance and geographic proximity simultaneously. A Starbucks 200 meters away is more relevant than a better rated one 20km away. How do you design location search?
17. Debug why a POST route is returning the wrong status code.
18. Design a system to charge a customer idempotently even under network failure.
19. How would you build a rate limiter for Stripe's API that absorbs traffic spikes? Explain your strategy first, then code it.
20. Design a system that routes payments through the optimal processor based on currency, geography, cost, and success rates

Common questions about system design questions

Related patterns