A system design interview framework you can say out loud
A framework for a system design interview is a fixed order of steps plus a sentence that opens and closes each one: requirements, the numbers that matter, the API and data, a simple design end to end, two deep dives, then a wrap-up. The order keeps you from running out of time; the spoken signposts let the interviewer follow you and step in at the right moment.
Key points
- Use the same six steps every time, so your attention goes to the problem and not to what comes next.
- Open each step with one sentence that says what you are about to do, and close it with one that says what you decided.
- Estimate only the numbers that change a decision, and say which decision each one changes.
- Get a plain design working end to end before you make any part clever.
- Check in at the joins between steps, not in the middle of a thought.
The six steps and a time budget
The steps below follow the order most public prep guides describe, with a budget for a 45-minute round after introductions. Treat the minutes as a warning light: if you are still on requirements at minute twelve, say so and move on.
| Step | Minutes | What you leave behind |
|---|---|---|
| 1. Requirements | 4 to 6 | Three to five functional requirements, the qualities that matter (latency, availability, consistency) and what is out of scope. |
| 2. Numbers | 2 to 4 | Two or three estimates, each tied to a decision: one database or many, cache or not, push or pull. |
| 3. API and data | 5 | The calls the outside world makes and the main entities with their keys. |
| 4. Simple design | 8 to 10 | Boxes and arrows that serve every functional requirement, walked through one request at a time. |
| 5. Deep dives | 12 to 15 | The two parts most likely to break the requirements, hardened with a choice and its cost. |
| 6. Wrap-up | 3 to 5 | The weakest point left, how you would monitor it, and what version two adds. |
Signposts: the sentences between the steps
Interviewers take notes while you talk, and they score what they can follow. A signpost is a short sentence that tells them where you are. It costs five seconds and saves the minutes you would otherwise lose when the interviewer has to stop you to ask what you are doing.
Use the same signposts every time you practise until they come out without thought. They also buy a moment to think when you need one.
“Before I draw anything, I’d like five minutes on what the system has to do and how big it is.”
“So the requirements are A, B and C, and I’m leaving D out of scope unless you want it. Shall I do some quick numbers?”
“That number tells me the writes fit on one primary database, so I’ll keep the storage simple for now.”
“Here is the simplest version that works. Let me walk one request through it, then pick the parts to harden.”
“The two places I think this breaks first are the scheduler and the send path. I’ll start with the scheduler unless you’d rather I go elsewhere.”
“To wrap up: the weakest part left is X, I’d watch it with this metric, and next I would add Y.”
A worked example: appointment reminders
Prompt: design the reminder service for a booking app used by dental clinics. Patients get a text message 24 hours and 2 hours before each appointment.
Requirements. Functional: schedule two reminders per appointment, cancel them when the appointment is cancelled, move them when it is moved, and let a clinic see what was sent. Qualities: a reminder should arrive within a few minutes of its time, never twice, and never after a cancellation. Out of scope: the booking flow itself and two-way chat.
Numbers. Say there are 40,000 clinics and 3 million appointments a day, so 6 million reminders a day, about 70 a second on average. Reminders bunch up at round hours, so plan for ten times that, 700 a second, at the peak. Each scheduled reminder is a row of about 200 bytes: 6 million rows a day is around 1.2 GB, small enough for one well-indexed relational database. The number that matters most is the peak send rate, because the text-message provider has its own rate limit.
API and data. Booking events (created, moved, cancelled) arrive from the booking service. One table holds reminders: id, appointment id, send time, status (scheduled, sending, sent, cancelled) and a version number. An index on (status, send time) lets a worker fetch what is due.
Simple design. The booking service publishes events to a queue. A scheduler consumes them and writes or updates reminder rows. Every few seconds, worker processes claim due rows, mark them as sending, call the provider and mark them sent. A clinic dashboard reads the same table.
Deep dives. First, “never twice”: a worker can crash after the provider accepted the message but before the row says sent. Use an idempotency key per reminder with the provider where it supports one, and claim rows with a lease that expires, so a crashed worker’s rows are picked up again. Second, “never after a cancellation”: the cancel event can race the worker. Check the row’s version just before the send call, and accept that a message already handed to the provider cannot be recalled. Say that last part out loud; an honest limit is a strong signal.
Wrap-up. The weakest part left is the provider: if it slows down, due reminders pile up. Watch the age of the oldest due reminder and alert when it passes five minutes. Version two adds a second provider and per-clinic quiet hours.
Where to check in, and where not to
Check in at the joins: after the requirements, after the simple design, and before each deep dive. A question such as “does this scope match what you had in mind?” gives the interviewer a natural place to redirect you, and many will, because they need signal on specific parts.
Do not ask for permission in the middle of a thought, and do not ask “is this right?”. The first breaks your flow; the second hands the decision to the interviewer, which is the opposite of what the round measures. State the choice, then ask if they want you to go deeper or move on.
Common mistakes
- Drawing before the requirements are written down, then designing for a problem nobody asked.
- Estimating numbers that change nothing: storage for ten years when the question is about latency.
- Going deep on the first interesting component and having no end-to-end design at minute thirty.
- Silent drawing. The board shows boxes; only your voice shows why they are there.
- Treating the framework as a script and skipping the part the interviewer just asked about.
- Leaving no time for the wrap-up, which is where you show you know your design’s weak points.
What changes at lead level
At senior and lead levels the steps stay the same, but you are expected to drive them without prompts, to put numbers on the qualities (“99.9% of reminders within five minutes”), and to raise operations, cost and rollout yourself. In the example above, a lead answer would also say how to migrate the old reminder system without double-sending during the switch.
Questions
Should I memorize one framework?
Memorize the order of the steps and your signposts, and leave the answers unscripted. The order frees your attention for the problem; a memorised design breaks the moment the interviewer changes a requirement.
How much estimation is enough?
Two or three numbers, each tied to a decision. If an estimate would not change what you draw, skip it and say why.
What if the interviewer wants a different order?
Follow them. A framework is a default for when nobody steers; when the interviewer steers, they are telling you where they need signal.
Practise this out loud with Vera
Mockich’s system design round runs 45 to 50 min on one design, on a shared whiteboard that Vera reads while you talk: requirements, a high-level design, a deep dive into the riskiest part, then twists in load or failure, and a wrap-up. Vera gives at most two small nudges. The report scores requirements and scoping, structure and driving, api and data model, architecture, depth, trade-offs, scale and failure handling, communication (plus operability and cost, scope and influence at lead) and quotes your reasoning.
Related guides
Sources
We read these guides on 2026-11-03 for the order of steps they share; the step order is the one these guides share, and the System Design Primer’s four-step outline (CC BY 4.0) is one of them; the signposts, the reminder example and its numbers are our own.
- [1] Hello Interview, Delivery Framework (System Design in a Hurry)
- [2] interviewing.io, A Senior Engineer’s Guide to the System Design Interview
- [3] Donne Martin, The System Design Primer: how to approach a system design interview question (CC BY 4.0)
- [4] ByteByteGo, A Framework for System Design Interviews
- [5] Hello Interview, Mastering Estimation