In this article
Before you start
This method sits inside system design as a whole: the ideas a design uses, such as caching, replication and consistent hashing.
Everything else, including the vocabulary of the round, is explained below.
Why interviewers ask this
The system design interview is often used to judge seniority, because it tests how you reason about a design you have not seen, and a memorised answer cannot show that. A candidate who recites a famous architecture fails the first time the interviewer changes a requirement, and a candidate who draws boxes without stating why fails for the opposite reason: nothing shows that the design answers the problem.
What the round separates is judgement under ambiguity. The question is deliberately underspecified, so the interviewer is watching whether you ask what matters, choose a simple design that meets it, find the part that will break first, and say what you gave up. A fixed order gives you somewhere to stand while you do this, which is why published frameworks exist and why they look alike.
The system design interview from first principles
In plain words
- System design interview
- A system design interview is a spoken round in which you design a service that must handle many users, such as a cache or a payment flow, by stating requirements, drawing the main components and explaining the trade-offs out loud.
- Percentile
- A percentile is the value below which a stated share of measurements fall; the 99th percentile is the time that 99 of every 100 requests beat.
Think of the round as planning a new restaurant with the owner. You first ask who it is for and how many guests will come. That is the requirements. Next you sketch the kitchen and the dining room, which is the simple design. Only then do you ask what happens on a Saturday night when everyone arrives together. That is the deep dive. The analogy breaks in one place. A restaurant owner will tell you the guest count if asked. An interviewer often expects you to propose a sensible number and say so.
In one precise sentence: the framework moves from what the system must do, to the numbers that matter, to the nouns and the interface, to a simple design, to the part that breaks, and ends with what you traded away.
Step-by-step description
- List what the system does and the qualities it needs.
- Calculate only numbers that change the design.
- Name the entities and the calls.
- Draw the smallest design that works.
- Fix the place where it breaks first.
- Say what you gave up and what to measure.
- Clarifying requirements turns an open prompt into a short list of things the system must do and qualities it must have.
- A deep dive is a focused look at the one or two places where the simple design will fail the non-functional requirements.
Step 1: Clarify the requirements
Clarifying requirements means turning an open prompt into a short list of things the system must do and qualities it must have. A non-functional requirement is a quality such as speed or availability rather than a feature. ByteByteGo's published framework opens the same way: ask questions to understand the exact requirements, and write down any assumptions the interviewer asks you to make (ByteByteGo, read October 2026).
Read the list back to the interviewer. Ask about users, the read-to-write balance, latency targets and what happens when something fails. What you now know: the list is the contract for every later step, so changes to it are announced, not silent.
Step 2: Estimate only what changes the design
An estimate is a rough calculation of load or storage that you do to choose between designs, not to display arithmetic. ByteByteGo's chapter places back-of-the-envelope calculations in its high-level design step, to check that the blueprint fits the scale constraints (ByteByteGo, read October 2026). This page gives estimates their own step, between requirements and interface, and applies one test to every number: would a different answer put a different box on the board?
The input is a stated assumption such as requests per day, the change is a rate per second, and the output is a decision such as one database or many. The worked example below does a full estimate once. The shortcut that saves the most time is dividing a day into 86,400 seconds (24 × 60 × 60)1 and using a peak of a few times the average (a rule of thumb, not a measured figure).
Text description of the diagram
- An estimate is a rough calculation of load or storage that you do to choose between designs.
- Estimate a number only when a different answer would put a different box on the board.
Step 3: Name the entities and the interface
The entities are the nouns the system stores and moves, and the interface is the small set of calls a client uses to act on them. This page treats them as a step of their own, so that every later box can be tied to a call.
The input is your functional list, the change is a draft of nouns and endpoints, and the output is a vocabulary shared with the interviewer. Present the list as a first draft you will refine. What you now know: every box in the next step exists to serve one of these calls. Many interfaces follow REST (representational state transfer), a common style of web interface; see the REST application programming interface (API) interview questions.
Step 4: Draw the simple design
The simple design is the smallest set of components that meets the functional requirements, drawn before any scaling concern is allowed in. Draw a client, one service, one data store and the arrows that carry each requirement, then walk one request through it aloud.
ByteByteGo's chapter suggests box diagrams of the key components, such as clients, web servers and data stores, drawn with the interviewer as a teammate (ByteByteGo, read October 2026). The input is the interface of Step 3, the change is a drawing that answers each call, and the output is a baseline you can attack. Add no cache (a fast copy of data), queue (a waiting line for work) or shard (a slice of the data on its own database) until a need appears. What you now know: a simple design gives Step 5 something concrete to break.
Step 5: Go deep where the design breaks
A deep dive is a focused look at the one or two places where the simple design will fail the non-functional requirements. Pick them by asking which Step 2 assumption is largest and what happens when a server is slow.
Tail latency is often the culprit when one request fans out to many servers; an overloaded database or a hot key (one very busy key) can be another. In the paper "The Tail at Scale", Dean and Barroso show that if one request in 100 to a server is slow and a user request must collect responses from 100 such servers, then 63% of user requests will take as long as the slow case or longer (Dean and Barroso, 2013).
The paper's best-known remedy is the hedged request: send a second copy to another replica after a short delay. In its test a 10-millisecond hedge cut the 99.9th-percentile latency from 1,800 to 74 milliseconds for 2% more requests (Dean and Barroso, 2013). What you now know: averages hide the problem, so name the percentile you are designing for.
Step 6: Close with trade-offs and failure
The close is a short statement of what you traded away, what would break first, and what you would measure in production. Google's site reliability book defines a service level objective as "a target value or range of values for a service level", measured by a service level indicator (SLI), which is a quantitative measure of one aspect of the service (Google site reliability engineering (SRE) book, 2016). Naming one such objective, such as a target for 99th-percentile latency (say, under 200 milliseconds), turns "it should be fast" into something checkable.
The input is the design after the deep dive, the change is a list of two or three trade-offs, and the output is a finished answer with its own review. Say what you would build next if given another hour. What you now know: an answer that ends on its own weaknesses sounds like engineering, not salesmanship. Related designs show the same close: the distributed cache and the payment system both end on failure behaviour.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Two small calculations show why the order matters: the share of slow requests as fan-out grows, and a capacity estimate. For the first, if each call is slower than its own 99th percentile with probability 0.01, independently, the chance that a request containing calls has at least one slow call is .1 The 100-call row of the table matches the 63% in the paper.
| Calls per request | Requests with at least one slow call |
|---|---|
| 1 | 1.0% |
| 10 | 9.6% |
| 30 | 26.0% |
| 100 | 63.4% |
The paper's second case, one slow call in 10,000 across 2,000 servers, gives 18.1%, almost one request in five.1
Text description of the diagram
- If each call is slower than its own 99th percentile with probability 0.01, the chance that a request has at least one slow call is 1 - 0.99^n.
- That gives 1.0% for one call, 9.6% for 10 calls, 26.0% for 30 calls and 63.4% for 100 calls.
An illustrative capacity estimate for Step 2: with 10 million requests a day, the average is about 116 requests per second, and a peak of three times the average is about 347 per second.1 At ten reads per write, writes average about 10 a second. These inputs are assumptions for the arithmetic, not data about any real service; the point is that the numbers are small enough to keep one database in the first design.
At 1 billion requests a day the same arithmetic gives about 11,574 per second on average, about 34,722 at a 3x peak and about 1,052 writes per second at ten reads per write, which is a very different load from the first case.1 Whether one database still copes at that rate depends on the hardware, the query mix and the data size, none of which this arithmetic knows, so treat it as the cue to ask about them and to measure, not as a threshold.
Trade-offs and edge cases
A framework helps most when you hold it loosely, because some interviewers will pull you off the order. As of October 2026 the ByteByteGo chapter presents four steps: understand the problem and scope, propose a high-level design, a deep dive and a wrap-up. This page splits the same ground into six (ByteByteGo, read October 2026).
The same chapter gives a time budget for each of its four steps: 3 to 10 minutes to understand the problem and establish scope, 10 to 15 minutes to propose a high-level design and get buy-in, 10 to 25 minutes for the deep dive, and 3 to 5 minutes to wrap up (ByteByteGo, read October 2026). Treat the ranges as a guide for pacing, not as a rule. Two edge cases matter.
First, interviewers sometimes want the design led by their questions. If they interrupt with a deep dive in Step 3, follow them, and return to the skipped step afterwards. Interviewers differ here: the chapter notes that every interview is different. Read the first few minutes to see which you have.
Second, the framework is for distributed-systems prompts. A machine learning system design round adds data, features and evaluation as its own steps, which this method does not cover. The wider ideas under it, such as consistent hashing and service level objectives, belong to system design as a whole.
How to answer it in an interview
When asked how you approach a system design question, describe the order and one reason for each step. Keep it short enough to leave room for the interviewer's question.
How do you approach a system design problem?
I start by clarifying requirements, both what the system does and the qualities it needs, and I read them back. Then I estimate only the numbers that would change the design. I define the entities and the interface, draw the simplest design that works, and walk one request through it. After that I look for where it breaks first, often tail latency or a hot spot, and fix that specifically. I finish with the trade-offs I made and what I would measure in production.
The spoken structure is: requirements, numbers that matter, interface, simple design, where it breaks, trade-offs. The answer is 84 words, sayable in under a minute.
Common mistakes
(wrong) "Let me start by drawing the architecture." Starting with boxes means you have not agreed what the system must do. (right) "Before I draw, can I confirm the main requirements and the scale?"
(wrong) "I will estimate every number first." This burns minutes on arithmetic that changes nothing. (right) "I will estimate only the number that decides between one database and several."
(wrong) "Average latency is fine, so the design is fast." Averages hide the slowest requests that fan-out multiplies, so a fast average can sit beside a slow experience for many users. (right) "I am designing for the 99th percentile, and with this many calls I need to cut the call count."
(wrong) Adding a cache and a queue in the first drawing. (right) Draw the simple design first and add each component only when a requirement or a number calls for it; each component adds a failure mode you must defend.
Follow-up questions
How do I approach a system design interview?
Follow one order: requirements, the numbers that matter, entities and interface, a simple design, a deep dive on what breaks, and the trade-offs. Say the step you are on, so the interviewer can steer you.
How do I prepare for a system design interview?
Practise the order on three or four standard prompts until the steps are automatic, then vary the requirements to see what changes. A web crawler and a rate limiter are good prompts for applying the framework end to end. Prepare questions to ask the interviewer for the end of the round too.
What are the top 5 system design interview questions?
No source publishes an official ranking, and any list is a candidate report. Common practice prompts include a cache, a rate limiter, a web crawler, a payment system and a news feed.
What if the interviewer says the system gets 1 billion requests a day?
A day is 86,400 seconds, so 1 billion requests is about 11,574 per second, about 34,722 at a 3x peak and about 1,052 writes per second at ten reads per write (assumed inputs). The load is a hundred times the 10-million-a-day example, so say the new numbers aloud and ask what the database, the read-to-write mix and the data size look like before you decide. Whether one database still copes depends on those answers, not on the request count alone; if it does not, the deep dive is where you weigh options such as read copies or splitting the data, and say what each costs.
How do I pick the deep-dive target, and what does a senior answer add?
Pick the part where your largest Step 2 number or the least reliable component meets a requirement from Step 1. A senior answer goes further than naming the fix: it says why the alternative loses under these requirements, what the fix costs, and which metric would show it failing in production. It also names the second-most-likely failure and when you would revisit it.
Is there a framework for ML system design interviews?
Yes, and it keeps the same spine of requirements, simple design, deep dive and trade-offs, but adds data, features, modelling and evaluation as steps of their own. The machine learning system design page covers that round.
- Use one order: requirements, numbers, interface, simple design, deep dive, trade-offs.
- Estimate only what would change the design.
- Draw the simple design first; add components when a requirement demands them.
- Name the percentile you design for; an average hides the slow requests.
- End on what you traded away and what you would measure.
Sources
- A Framework For System Design Interviews (System Design Interview course, chapter 3) — ByteByteGo (Alex Xu; print edition 2020, online chapter read 2026-10-26), 1 Jan 2020
- The Tail at Scale — Communications of the ACM 56(2), 74-80 (Dean and Barroso, 2013), 1 Feb 2013
- Service Level Objectives (Site Reliability Engineering, chapter 4) — Google SRE book, O'Reilly 2016, 1 Apr 2016
