🏗️
Frameworks & Method · 9 min read
System Design Interview Primer: A Repeatable Approach
Drive the design: requirements, estimates, high-level design, then one deep dive.
System design interviews are open-ended by design, and that scares people. The fix is a repeatable process you drive yourself. Interviewers are not looking for the one correct architecture — they want to see you scope a vague problem, make reasoned trade-offs, and go deep on at least one component. This primer gives you that process and the building blocks to reach for.
The six-step approach
RequirementsClarify functional needs and non-functional ones (scale, latency, consistency, availability). Write them down.
EstimatesBack-of-envelope: users, QPS, storage, bandwidth. This justifies later choices.
API & data modelDefine the core endpoints and the main entities and relationships.
High-level designDraw the boxes: clients, load balancer, services, databases, cache, queue.
Scale itFind bottlenecks and address them: replication, sharding, caching, CDN, async processing.
Trade-offsName what you optimized for and what you gave up. There is no free lunch.
Building blocks to reach for
- •Load balancing to spread traffic and remove single points of failure.
- •Caching (client, CDN, application, database) to cut latency and load — and a plan for invalidation.
- •Database choice: relational for strong consistency and joins, NoSQL for scale and flexible schema.
- •Replication and sharding for read scale and horizontal write scale.
- •Message queues for async work, smoothing spikes, and decoupling services.
- •The consistency vs availability trade-off (CAP) — know which your system needs and why.
How to stand out
- •Drive the conversation. Don't wait to be asked the next question — state what you'll cover next.
- •Justify with numbers from your estimates ('at 10k QPS, a single database won't hold, so I'll shard by user ID').
- •Go deep on one component when invited — pick the most interesting bottleneck and design it fully.
- •Call out failure modes and how the system degrades. Reliability thinking signals seniority.
💡 A clean, well-reasoned design of a simpler system beats a hand-wavy sketch of a complex one. Depth and trade-offs win over breadth.
Run a technical mock
Practice explaining a design out loud and get feedback on structure and trade-offs.
Run a technical mock →