System Design Interview Framework — Step-by-Step Approach
A repeatable path: clarify, estimate, sketch, choose storage, scale, deep dive, find failures, summarize.
A system design interview without a framework is a conversation that goes nowhere. The interviewer gives you "design Twitter" — and without a structure, most candidates start drawing boxes immediately, skip requirements entirely, and end up defending architecture decisions they never justified.
The framework fixes that. It gives you a proven sequence that every successful candidate uses: (1) Clarify the requirements so you're both solving the same problem. (2) Estimate capacity so your architecture choices are grounded in real numbers. (3) Sketch the high-level design — just boxes and arrows, no code. (4) Drill into the most interesting component in depth. (5) Address failure modes and trade-offs. (6) Summarize the design and what you'd change with more time.
Interviewers at Google, Meta, and Amazon explicitly score candidates on whether they follow this kind of structured approach. It demonstrates seniority: senior engineers don't dive into implementation; they frame the problem first.
Key concepts
Step-by-step approach
- 1
Restate the problem in one sentence to confirm shared understanding.
- 2
Ask 3-4 clarifying questions: expected scale (DAU, QPS), read/write ratio, latency requirements, consistency needs, and geographic scope.
- 3
Write down confirmed constraints visibly — never design against assumptions you haven't stated out loud.
- 4
Do a 2-minute back-of-envelope estimation: daily active users → requests per second → storage per day → storage per year.
- 5
Draw the high-level diagram: clients, load balancer, API layer, storage tier, cache — just boxes and arrows.
Key trade-offs
Breadth vs. depth
Covering the full system at high level demonstrates architectural thinking; drilling into one component demonstrates engineering depth. Do both — breadth first, then pick one area to go deep.
Simplicity vs. completeness
Starting with the simplest design and adding complexity only where justified is a sign of senior thinking. Starting with distributed caches and message queues before understanding the load is a red flag.
Speaking vs. drawing
Talking through your reasoning while drawing keeps the interviewer engaged. Silent drawing leaves them guessing what you're thinking.
Common pitfalls
Jumping straight to the solution: Not asking clarifying questions is the single fastest way to fail a system design interview.
Designing in silence: If you stop talking for more than 30 seconds, the interviewer loses signal on your thought process.
Skipping failure modes: An architecture with no failure analysis is incomplete — always ask 'what happens when X fails?'
Interview questions on this topic
Practice answering these with AI feedback → Start on CrackLab
Continue learning — explore 207 more topics on CrackLab DesignHub
From Classic HLD designs (Twitter, YouTube, Uber) to LLD patterns, distributed systems, databases, and company case studies.
Related topics
Turn a product idea into a production blueprint: components, data, flows, scale, failures, and trade-offs.
Estimate users, QPS, storage, bandwidth, memory, fanout, and cost before choosing architecture.
Understand response time, work per second, p95/p99, and why averages hide user pain.