0% completed
System Design Interviews - A step by step guide
On This Page
Step 1: Clarify the Requirements
Step 2: Estimate the Scale
Step 3: Define the API
Step 4: Define the Data Model
Step 5: Draw the High-Level Design
Step 6: Go Deep on Two or Three Things
Step 7: Bottlenecks and Failure Points
The Steps Are a Spine, Not a Script
Most engineers find system design interviews harder than coding interviews, and the reason is not usually knowledge. It is that the question has no fixed format. You are given one sentence, a blank page, and about forty five minutes, and nobody tells you what a complete answer looks like.
A process fixes that. Not because there is one right design, but because having a fixed order to work in means you always know what to do next, and at the end you can tell whether you covered everything.
These are the seven steps. Every case study in this course follows them, and so should you.
The minutes are a guide, not a rule. What matters is how you divide the time: a short opening, a fast middle, and most of your time spent deep in two or three things. Candidates who fail almost always do the reverse and spend half the interview on the first two steps.
Step 1: Clarify the Requirements
Never start designing until you know what you are designing. Spend about five minutes agreeing on what the system does and how well it has to do it.
Ask for functional requirements, which are the features, and pick three to five. For a Twitter-like service that might be posting, following, and the home timeline. Then say out loud what you are leaving out, such as search, direct messages, and trending topics. The interviewer will redirect you if you cut the wrong thing, which is exactly what you want to happen in minute two rather than minute thirty.
Then ask for non-functional requirements, which are the numbers: how many users, how much traffic, how fast a read has to be, how much staleness is acceptable. If the interviewer will not give you a number, state your own assumption and move on.
This step has its own lesson, because the scoping skill is what most of the marks depend on: Functional vs. Non-functional Requirements.
Step 2: Estimate the Scale
Turn the numbers you just agreed into figures you can design against. Three or four minutes, done out loud, using round numbers.
You need four things: requests per second at peak, storage over some horizon, bandwidth in and out, and the read to write ratio. That last one is the most useful of the four and the one candidates most often skip, because it decides almost every choice that follows. A hundred reads per write points you at caches and replicas. The reverse points you at queues and write-optimised storage.
The point is not precision. It is that the numbers should visibly drive your later choices, so that when you add a cache in step five you can say which figure made you do it. Full method in What are Back-of-the-Envelope Estimations?.
Step 3: Define the API
Write the handful of API calls your features imply. This takes three or four minutes and it does two jobs.
First, it forces the requirements to become concrete. If you cannot write the signature, you have not defined the feature precisely. Second, it catches misunderstandings early: an interviewer who disagrees with your design will usually say so the moment they see the parameters.
Keep it to the three or four calls that matter. Notice the cursor in getTimeline, which is worth a sentence: timelines are paginated by cursor rather than page number, because the list shifts while the reader scrolls.
Step 4: Define the Data Model
Name the entities, the fields that matter, and how they relate. Then say where each one is stored.
For a Twitter-like service:
| Entity | Key fields |
|---|---|
| User | userId, name, email, createdAt |
| Tweet | tweetId, userId, content, createdAt |
| Follow | followerId, followeeId |
| Media | mediaId, tweetId, path |
The valuable part is not the table, it is the sentence after it. State the two or three hot queries, then pick the store that serves them. "The hot queries are get a tweet by id and get the recent tweets of the people I follow. Neither needs a join, both are lookups by key, and there are billions of rows, so a wide-column store fits better than a relational one." That is a design decision with a reason attached.
Large files do not go in the database. Media goes to object storage and the row holds the path.
Step 5: Draw the High-Level Design
Now draw boxes. Five or six of them, from the client inward, and say why each one is there as you add it.
Build it up rather than revealing it. A diagram with fifteen components appearing at once reads as a memorised template. One that grows while you explain each addition reads as reasoning, and reasoning is what is being marked.
Ten minutes. At the end of it you should have an end-to-end path: a request can enter, be served, and a response can get back. Do not go deep yet. If the interviewer asks about a detail early, follow them, but try to get the whole design agreed first so you both know what has been covered.
The components available to you, and what each is for, are in System Design Master Template.
Step 6: Go Deep on Two or Three Things
This is the longest step and most of the marks come from it. Pick the parts that are actually hard for this particular system and go into detail on them.
For a Twitter-like service the hard parts are timeline generation and the celebrity problem. For a URL shortener they are key generation and cache sizing. For a chat system they are connection handling and message ordering. Every design has two or three of these, and picking the right ones is itself part of the assessment.
Let the interviewer decide what you talk about. If they ask about something, that is the thing they want to hear about, so go there and stay there until they move you.
When you present an option, present the alternative with it and say why you chose one. "I could generate every follower's timeline at write time or build it at read time. Write time makes reads cheap, which suits a hundred to one read ratio, but a celebrity with fifty million followers turns one post into fifty million writes. So I would fan out on write for normal accounts and merge celebrity posts in at read time." That is what a strong answer sounds like.
Step 7: Bottlenecks and Failure Points
Close by saying where the system reaches its limit and where it breaks. These are two different questions and a complete answer covers both.
Where does it saturate first? Every design has one component that reaches its limit before the others. Name it, say at what number that happens, and say what you would do. A single primary that takes every write. One shard that holds a celebrity's data and receives ten times the traffic of its neighbours. A cache that only helps while the working set fits in memory. Saying "at roughly fifty thousand writes per second the single primary is the limit, and that is when I would shard by user id" shows you understand your own design's limit.
What happens when something dies? Where are the single points of failure? Is there more than one of each thing that matters? If a node goes down, does the system carry on in a reduced state or stop? What do you do about a queue that is backing up, or a dependency that has gone slow rather than gone down?
Then say how you would know. Name the two or three numbers you would watch for this system, not a generic list. For a timeline service that is read latency at the ninety-ninth percentile, fanout queue depth, and cache hit rate.
Five minutes is enough for all of it. Volunteering this before you are asked is one of the clearest signals of seniority available to you, because most candidates present a design as though nothing ever fails and nothing ever fills up.
The Steps Are a Spine, Not a Script
Two things to keep in mind so this does not become rigid.
Interviewers interrupt, and that is fine. If they move you to the data model while you are still on the API, follow them. The steps are there so you know what you have not covered yet, not to control the conversation.
Some questions need a different order. A typeahead suggestion service is hard to estimate before you have sketched the design, so the estimation can come later. Say so when you skip ahead: "I will come back to the numbers once the design is clearer."
What should not change is how the time is divided. Five minutes at the start, most of the time in the middle two steps, and a few minutes at the end on what breaks.
💡 In the interview: say the plan out loud in the first thirty seconds. "I'll spend five minutes on requirements and rough numbers, then sketch the high-level design, then go deep wherever you want." An interviewer who hears that already knows you have done this before, and it gives you time to run the requirements phase without them wondering when you are going to start designing. Then watch the clock, and protect the deep dive. If you are twenty minutes in and still drawing boxes, move on to the interesting part and say you are doing it.
Key takeaway: the seven steps are clarify the requirements, estimate the scale, define the API, define the data model, draw the high-level design, go deep on two or three things, and close on bottlenecks and failure points. They exist so that you always know what to do next and can tell at the end whether you covered everything. Keep the opening short, spend most of your time deep in the parts that are genuinely hard for this system, and finish by naming both where the design reaches its limit and where it breaks. Follow the interviewer when they change the topic, and say out loud when you are changing the order.
Next, the two steps worth the most marks get a lesson each: scoping in Functional vs. Non-functional Requirements, and the numbers in What are Back-of-the-Envelope Estimations?.
Download Mastering System Design Interview in 7 Steps (pdf).
Yung Chau
· 3 years ago
So I assume I should attempt the problem first myself and see what I missed reading through.
What do I do after that?
designgurus.cedar998
· 5 months ago
Step 7 seems to conflate performance (bottlenecks) with reliability (consequences of failure). I find it strange that all of the "bottlenecks" questions relate to reliability, not throughput or other performance concerns.
Panos
· 3 years ago
What‘s the benefit of having a file storage system instead of using database blob storage?
Arturo Bravo
· 3 years ago
hi
On This Page
Step 1: Clarify the Requirements
Step 2: Estimate the Scale
Step 3: Define the API
Step 4: Define the Data Model
Step 5: Draw the High-Level Design
Step 6: Go Deep on Two or Three Things
Step 7: Bottlenecks and Failure Points
The Steps Are a Spine, Not a Script