The System Design Interview Framework
A script you can run on any prompt. Six steps, a time budget for each, and the exact sentences that move you between them.
Covers: A repeatable 6-step script, time budget, whiteboard technique, what to say at each stage, recovering when stuck
You cannot memorise designs - there are too many. What you can memorise is a process that turns any prompt into a structured 45 minutes. Interviewers notice structure immediately, and a candidate who is visibly following a method reads as someone who has done this before.
The six steps, with their time budget
Tap each step for what to say and the trap to avoid. Timings assume a 45-minute interview.
Flow
- 1 · Clarify2 · Estimate
- 2 · Estimate3 · API + data model
- 3 · API + data model4 · High-level design
- 4 · High-level design5 · Deep dive
- 5 · Deep dive6 · Scale & fail
30-second answer
Open by restating the problem and proposing an agenda. Ask for scale numbers before drawing anything. Estimate out loud and immediately convert the numbers into a design decision. Sketch the API and data model. Draw a complete end-to-end design and trace one write and one read through it. Then go deep wherever the interviewer points, and finish by identifying your own bottleneck and the central trade-off. Narrating the agenda turns the interview from an interrogation into a design review, which is exactly the collaboration being assessed.
Openers that work
| Moment | Say this |
|---|---|
| Opening | “Let me restate it to check I have it right… I'll spend a few minutes on requirements and scale, then sketch the API, then draw an end-to-end design, and we can go deep wherever you'd like.” |
| Asking for numbers | “Before I draw anything - roughly how many daily active users, what's the read-to-write ratio, and how much staleness is acceptable? Those three change the design more than anything else.” |
| After estimating | “So writes are about 300 a second, which one primary handles comfortably, and reads are 35,000, which is the interesting problem. I'll focus my complexity there.” |
| Starting the diagram | “I'll start deliberately simple and add components only where I can name the bottleneck they remove.” |
| Making a choice | “I'll use X here. The alternative is Y, which would be better if Z - but given our consistency requirement, X wins.” |
| Finding your own bottleneck | “The weak point in what I've drawn is the single primary. At 10× write volume that fails first, so here's how I'd shard it…” |
| When stuck | “I'm weighing two options here. A gives us X but costs Y; B is the reverse. My instinct is A because of our latency requirement - does that match how you'd think about it?” |
| Closing | “To summarise: the core trade-off is availability over strict consistency on the read path, which is why I chose the cache-plus-replica design and accepted a few hundred milliseconds of staleness.” |
Whiteboard technique
- Left to right: client → edge → service → storage. Everyone reads diagrams this way; fighting it costs your interviewer attention they could spend on your ideas.
- Boxes and arrows only. No icon sets, no colours, no artistry. Label every arrow with what flows along it.
- Reserve a corner for requirements and estimates, and point at it when justifying a decision.
- Leave whitespace. You will add components later, and a cramped diagram becomes unreadable exactly when it matters most.
- Number the flow - ①②③ along the write path - then trace it verbally. It forces completeness and makes the design legible.
Recovering when you are stuck
Say so, and say what you are weighing
“I'm not sure of the best approach here - let me think through the options aloud.” Vastly better than silence, and it invites collaboration.Return to first principles
What is the access pattern? What is the read:write ratio? What must be consistent? The answer is usually reachable from the requirements you already wrote down.Simplify to something that works
“The simplest thing that could work is a single database with an index. That handles our load until X. Let me start there and improve it.” A working simple answer beats a stalled clever one.Ask a targeted question
Not “what should I do?” but “does the product need this to be strongly consistent, or is a few seconds of staleness acceptable?” A good question demonstrates you know what the decision hinges on.
Say these points
- Restate, propose an agenda, and get numbers before drawing.
- Convert every estimate into an explicit design decision.
- Complete end-to-end design by roughly minute 20.
- Name the alternative you rejected and why, for every significant choice.
- Find your own bottleneck, and close with the central trade-off.
Avoid these mistakes
- Fifteen minutes of requirements and an empty whiteboard.
- Over-engineering for a scale nobody asked for.
- Technology names with no justifying constraint.
- Silent thinking.
- Never reaching failure modes.
Expect these follow-ups
- How does the script change for a 30-minute screen?
- What do you do if the interviewer gives no feedback at all?
- How do you handle being asked to design something in a domain you do not know?
Showing 1 of 1 questions for system-design-interview-framework.
Check your understanding
3 questions · no sign-up, nothing stored