The interview framework: nine phases to a working design
Most people who fail a system design interview know enough. They run out of time halfway through a clever idea and never show a design that works end to end. A fixed sequence of phases fixes that: it tells you what to do next at every minute, keeps you on what the interviewer is scoring, and gives you somewhere to return to when nerves hit. Every worked design on this site is written in exactly this order.
1. Why a framework
You finish
A complete simple design beats half of a brilliant one. The framework puts a working version on the board by about the halfway mark, so nothing later can leave you empty-handed.
You focus
Each phase produces something the next phase needs. You never solve a problem nobody asked for, and the deep dives are chosen by your own targets, not by whatever you happen to know well.
You recover
Under pressure, it's easy to freeze. A framework is a map: when you're lost, you know where you are and what comes next. Interviewers read that calm as seniority.
A good interview is also a conversation. The framework doesn't mean talking for an hour without a pause. Each phase ends with a short check: "does this match what you had in mind?". Those checks are where the interviewer steers you towards what they want to see.
2. The nine phases
The first six phases take about a third of the time and stay small on the board. Phases 7 and 8 are the heart of the interview. Phase 9 is where you show judgement.
3. Watch a board fill up
Here is the framework applied to a URL shortener (Design D01), phase by phase. The left column holds the short written notes; the right column holds the drawing and the deep dives. Keep the same layout in every interview, so you never wonder where something goes.
4. Each phase in detail
1Frame the problem~5 min of 60
Turn a one-line prompt into a problem you can design for. Ask the questions whose answers change the design, not every question you can think of.
Do
- Ask 5–8 targeted questions: who uses it, the biggest scale, what can't go wrong, what's explicitly out.
- Listen for the hard part hidden in the answers ("200,000 jobs at 09:00", "must never oversell").
- Write the answers as short notes.
Avoid
- Asking about everything ("which language?").
- Assuming the scale instead of asking.
- Starting to draw boxes.
"Before I design anything: is this for a few thousand users or hundreds of millions? And can a link ever change after it's created?"
Each long-form design starts with the questions worth asking, the likely answers and why they matter. Example: D21 §2.
2What it must do~3 min
Choose the three things users or clients must be able to do. Real products have hundreds of features; picking the few that define this one is part of the test.
Do
- Phrase each as an action: "A rider can request a ride", "The system can run a job at a time".
- List "Not now" items with a one-line reason each.
- Confirm the list with the interviewer.
Avoid
- Ten features "to be thorough". Every extra one costs time you'll need later.
- Mixing in qualities ("fast", "scalable"); those belong in phase 3.
"I'll focus on creating links, redirecting, and expiry. Analytics and custom domains I'll leave out unless you'd like them."
3How well it must do it~3 min
Write 3–5 measured targets specific to this system. These decide your deep dives later, so they matter more than they look.
Run through the checklist
- Consistency or availability: which wins when they conflict?
- Where it runs: phones on mobile data, browsers, devices.
- Load shape: peaks, bursts, read/write mix.
- Speed: which path, and what number at which percentile.
…and
- Data safety: can anything ever be lost?
- Security and privacy: who can see what.
- Surviving failures: what happens when a part dies.
- Rules: payments, personal data, regulation.
"Redirects under 50 ms at p99, because they're on every click. 100:1 reads to writes. A created link must never be lost, and links shouldn't be guessable."
"The system should be fast and scalable" says nothing. "Search under 300 ms at p99 for 50,000 queries a second" tells you, and the interviewer, where the hard work is.
4Numbers that change the design~2–4 min
Estimate only what decides something. A number that ends in "…so it's a lot" adds nothing. Finish each one with "→ so we…".
Usually worth it
- Peak requests per second on the hot path.
- Whether the data fits on one machine or in memory.
- Fan-out (one write reaching how many readers).
- The peak moment (top of the hour, a sale opening).
Usually skip
- Total storage over ten years "for completeness".
- Traffic on endpoints that are obviously small.
- Precise arithmetic: round boldly (Module 03).
"200,000 runs fall due in the same second at 09:00. That's the number that shapes dispatch. Everything else here is small."
It's fine to say you'll do the maths later, when a decision needs it. Many strong candidates estimate inside the deep dives instead of up front.
5The nouns~2 min
List the main entities the system stores and moves: User, Link, Click; Job, Run, Lease. Just names and a word each. Fields come later, next to the database, when a request needs them.
- Ask: who are the actors? What things do the three features create or read?
- Pick clear names. "Hold" says more than "Reservation2"; good naming is part of good design.
6The contract~4 min
Define how clients talk to the system: usually one endpoint per feature from phase 2.
Do
- Default to REST with plural resource names (
POST /links). - Take the caller's identity from the auth token, never from the body or the URL.
- Say where you need a push channel (WebSocket or Server-Sent Events) or an internal RPC (gRPC).
- Mention pagination and idempotency keys where they matter.
For pipelines
- Add a numbered data flow (input → steps → output), for crawlers, schedulers, analytics, streaming.
- Skip it when the system is simple request and response.
"POST /v1/links with the long URL returns the short code. GET /{code} redirects. The user comes from the session, not the request."
7First working version~12–15 min
Draw boxes and arrows that make every endpoint work, one request at a time. Walk each request from the client to the data and back, saying what state changes. Write the key table fields beside the database as you go.
Do
- Start with the simplest parts: stateless servers, one database, blob storage if needed.
- Trace a real example ("Asha posts a comment…").
- Keep a visible "Parked for later" list: "single database will be hot", "two schedulers would double-run".
Avoid
- Caches, queues and shards before a requirement asks for them.
- Every box you know, with no data flowing through.
- Going deep on one request before the others work.
"That works end to end, but I've parked three problems. The biggest is the hot row; I'd like to start the deep dives there."
8Make it hold up~15–25 min
Return to your targets from phase 3 and the parked list from phase 7, and harden the design. This is where seniority shows. Pick 2–4 deep dives in order of risk.
For each deep dive
- State the problem with a number ("one row takes ~500 updates a second; we need 100,000").
- Give 2–3 options, from naive to strong, with what each costs.
- Choose, say why, and update the drawing.
Usual candidates
- The hot spot: one key, one row, one huge customer.
- Consistency: double booking, double charging, duplicates.
- Failure: a node dies, a region goes, a deploy goes wrong.
- The system's own hard part (fan-out, time, GPUs…).
"Three options for the counter. A locked row is correct but serialised. Redis is fast but separate from the orders. Unit rows with SKIP LOCKED keep both, so I'd take that."
End with the final picture: redraw (or tidy) the board so it shows the hardened design, and walk one request through it.
9Follow-ups and wrap-up~5–10 min
Interviewers keep a list of "what if" probes: 10× traffic, a region outage, a hot key, a new feature, a cost cut. Answer each in under a minute: the problem, the mechanism, the cost. Then summarise:
- The trade-offs you made, one line each.
- What you'd monitor: 3–5 metrics, starting with your headline target.
- What changes at 10×.
"The main trade-offs: at-least-once with fencing instead of pretending exactly-once; correctness on the claim, availability on the API. I'd watch dispatch lag p99 first."
5. Plan the clock
Choose the interview length. Notice how the extra time goes almost entirely into making the design hold up; the opening phases barely grow.
Two checkpoints to watch: by about a third of the way through, the contract should be on the board; by about halfway, the first working version should handle every request. If you're behind at a checkpoint, say so and simplify: "I'll keep this part simple for now and come back to it."
6. What each level shows
| Level | Balance | How you lead | What gets you the offer |
|---|---|---|---|
| Mid-level | Mostly breadth | You drive phases 1–7; the interviewer often picks the deep dives | A complete, sensible working design, and good answers when probed |
| Senior | Breadth fast, then depth | You finish phases 1–7 briskly and choose 2–3 deep dives yourself | Spotting the real bottlenecks before being told, with options and numbers |
| Staff and above | Mostly depth and judgement | You shape the problem itself, and connect deep dives to cost, operations and the organisation | Anticipating failure, rollout and long-term trade-offs; clear, calm reasoning |
Whatever the level, interviewers score the same four things: navigating the problem (focus, prioritising, finishing), the design itself (parts that fit and meet the targets), technical depth (current technology and its limits), and communication (clear, collaborative, open to steering).
7. When you get stuck
Go back one phase
Lost in a deep dive? Re-read your targets. The answer to "what next?" is usually "which target isn't met yet?".
Walk one request
Trace a single concrete request through the drawing, out loud. Gaps show up immediately, and the interviewer sees you reasoning.
Name the bottleneck
"The single database is the problem here": naming it out loud buys thinking time and invites a hint.
Offer a choice
"I could go deeper on storage or on the fan-out. Which is more useful to you?" Steering together is good collaboration, not weakness.
Common mistakes:
- Drawing before asking.
- Ten features.
- Vague targets.
- Arithmetic that decides nothing.
- Adding caches and queues "because big systems have them".
- No working version by the halfway mark.
- Monologues that leave no room for questions.
- Defending a choice after the interviewer has shown its flaw (change it out loud instead).
8. Say it so it scores
The interviewer writes their notes from what they heard, not from what you thought. Two people can reason identically and get different scores because only one of them said the reasoning out loud. This section is about the few things worth saying: the choices, the reasons, the limits, and the moments you change your mind. Everything else (what a load balancer is, how a hash map works) can stay unsaid.
Decisions with a switch condition
A decision people can score has four parts: the options, what each one costs, your pick, and the condition that would make you switch. Most candidates say only the pick. The switch condition is the part that turns an opinion into engineering, and it gives the interviewer something to push on other than you.
| Ride hailing: where do drivers' current locations live? | |
|---|---|
| Heard as a guess | "I'll put locations in Redis." |
| Heard as a decision | "Two options: a table in Postgres, or keys in Redis. Postgres keeps history but each driver rewrites a row four times a second. Redis just overwrites a key in memory and forgets the old value. I'll use Redis, because nobody needs a location from five seconds ago. If support needs trip replays for disputes, I'd also append the points to a log in object storage." |
Describe the option you're turning down the way someone who likes it would. Turning down a weak version of the alternative is easy to spot, and it costs more trust than it saves time.
Ask, assume, or just decide
Asking about everything reads as not wanting to commit; asking about nothing reads as not noticing the gaps. One test sorts every question: would a different answer give a different design?
| A different answer would… | Do this | For example |
|---|---|---|
| …change the design, and the interviewer will tell you | Ask, and say what hangs on it | "Can a sent message be edited? If yes, clients need a version per message, not just an ID." |
| …change the design, but they say "you decide" | Pick the side that is more expensive to get wrong, and say so | "I'll plan for groups of up to 5,000. Building for 50 and being wrong is the costlier mistake." |
| …not change the design | Assume it out loud and keep moving | "I'll assume search is English-only for now; it doesn't change the architecture." |
The one thing never to do: ask, get a vague answer, then design as if you'd been given a precise one.
Keep the design the size of the problem
Every box you draw is something a person has to understand well enough to fix at 3 a.m. A design for 2,000 users with six services, an event bus and three databases shows knowledge and poor judgement at the same time. Start from the smallest design that meets the targets, and add a part only when a target forces it. For anything you leave out on purpose, name the trigger that would bring it in:
| Part | Add it when… (something you can measure) |
|---|---|
| Read replicas | The primary runs above roughly 60% CPU at peak, mostly on reads |
| A cache | A read path misses its latency target and the same keys are read over and over |
| A queue | A step is slow (over about a second), fails on its own schedule, or doesn't need the user to wait |
| Shards | Writes or data outgrow the largest machine you're willing to run, after tuning |
| A search engine | The database's own text search misses its latency target, or results need real ranking |
| Separate services | Different teams need to ship on their own schedules, or parts scale very differently |
Build or buy? Build what customers choose you for; rent everything else, behind an interface narrow enough that you could swap the vendor later. Count the cost of running a thing forever, not just of writing it. And say the trade out loud: "One Postgres holds this for years at these numbers. I'll spend the complexity on the matching service instead, and revisit storage at about ten times today's writes."
When you spot your own mistake
Finding a flaw in your own design and handling it calmly scores better than never showing one: it's a sample of how you'd behave in a real review. The handling takes about a minute and has four moves.
- Flag it, plainly, as soon as you see it. No apology.
- Bound it. Say exactly what it breaks and what still stands. This is the step people skip, and it's what protects the rest of your work.
- Pick a response: fix it now if everything after depends on it; note it in one sentence if it's contained; or name the fix and park it if it's big and the clock is short.
- Carry on at the same pace. Don't keep returning to it.
| Food delivery: orders were split across databases by restaurant, and now the "My orders" screen needs a customer's orders from every restaurant | |
|---|---|
| Collapse | "Hmm, actually this doesn't work… sorry, let me rethink the whole thing." |
| Recovery | "I need to correct something. Splitting by restaurant means a customer's history is spread over every shard, so 'My orders' would query all of them. The write path, the kitchen screens and the payment flow are unaffected. I'll keep restaurant as the split for orders and add a small per-customer index, written from the same order event. Moving on to delivery tracking." |
When the interviewer's question exposes a problem ("what if two couriers accept at once?"), work through it out loud and say the bad outcome yourself before fixing it. And when a probe turns out not to expose anything, say why the design holds. Don't change something that works because the question sounded doubtful.
When they point at one box
"How does the rate limiter actually work?" is not an interruption; it's where much of the score is. Zoom in one level at a time, so they can stop you where they want, and then zoom back out:
- Its job here: "It protects the payment provider, which allows us 5 calls a second."
- How it works: "A token bucket per merchant: tokens drip in at a fixed rate; a call spends one or waits."
- The choice inside it: "Bucket rather than a fixed per-second counter, because a counter lets a double burst through at the edge of each second."
- The number, and why: "Capacity 20, refill 5 a second: a short burst passes, the average can't exceed the provider's limit."
- Back out: "So a sale spike queues briefly instead of getting us blocked, which was the availability target."
If you don't know the inside, say what you do know, reason from what any such component must do, and name what you'd check. "I haven't run that product, but any queue has to decide whether to acknowledge before or after the work, and that decides whether we can lose or repeat a message. I'd check which it does." Bluffing is the expensive option.
Choose your own deep dives. Your "Parked for later" list from phase 7 is a menu: "The three hard parts are the hot restaurants on Friday night, keeping courier positions fresh, and paying out exactly once. Which would you like?" Interviewers usually pick one, and it's one you prepared.
"What changes at 10×?"
This is the most common closing question, and it checks whether you know where your own design gives out. Most parts just get more copies; the answer is the one or two that don't. Walk the drawing and sort every part into three groups, then say what stays the same, and give the order you'd try things in: tune, then buy bigger, then restructure.
Check which number grew before answering. More requests, more stored data, more users per item (fan-out) and sharper spikes are four different questions: spikes call for queues and shedding, not shards; more data with the same traffic calls for tiering and retention, not more servers. And if the honest answer at 100× is a different architecture, say that rather than stretching this one.
9. Practise for the best results
Knowing the framework is easy; using it under pressure takes repetition. This routine turns it into a habit in a few weeks.
- Learn the building blocks first. Work through Levels 1–3 of the modules. You can't choose between options you've never seen.
- Read one long-form design actively. For any of the 46 worked designs, cover each section and attempt it yourself first: guess the answers to the framing questions, write your targets, sketch the first version. Then compare.
- Do a timed run every few days. Pick a design you haven't read, set a 45- or 60-minute timer, and go through all nine phases on paper or a virtual whiteboard, speaking out loud. Stop at each checkpoint and note whether you were on time.
- Practise on the real tool. Ask which whiteboard the company uses, and practise drawing on it until boxes and arrows take no thought.
- Answer the follow-ups out loud. Each long-form design lists 10 or more probes. Time yourself: under a minute each, with problem, mechanism and cost.
- Review what you missed. Keep a notebook (see Start here) with the phase where each run went wrong. Most people have one weak phase; fix that one first.
- Use the review deck daily for five minutes, so facts and trade-offs stay fresh (review deck).
- Do mock interviews with a person in the last two weeks. Ask them to interrupt and steer; that's the skill a solo run can't train.
10. Check yourself
Which phase does each of these belong in? Your choice locks in and the explanation appears.
When is a capacity estimate worth doing?
What should be on the board by about halfway through?
What should choose your deep dives?
You've named two options, their costs and your pick. What turns that pick into a decision an interviewer can score?
Twenty minutes in, you realise your sharding key can't serve a main screen. What's the strongest move?
"What changes at 10×?" What is the answer the interviewer is looking for?
Next: see the framework in full on D21 · Distributed job scheduler, or learn the reasoning behind it in Module 05 · The design method.