Start here: the blank whiteboard#
TL;DRthe 30-second version
- A system-design interview is an open-ended prompt ("Design Twitter") and about 45 minutes. Without a procedure, candidates freeze or ramble and miss what the interviewer is scoring.
- The fix is a repeatable spine — the same eight steps every time — so you always have a defensible next move and cover the whole system before you run out of clock.
- The spine: (1) functional requirements, (2) non-functional requirements, (3) back-of-envelope estimate, (4) API, (5) data model, (6) high-level design, (7) deep dive, (8) bottlenecks and tradeoffs.
- The interviewer is scoring your process, not a memorized answer: can you scope an unbounded problem, justify numbers, defend choices, and find what breaks. The spine makes all of that visible.
Picture the first minute. The interviewer says "Design Twitter," caps the pen back on, and waits. That prompt has no edges. Twitter is timelines, follows, media, search, notifications, ads, direct messages, trending topics — you cannot design all of it in 45 minutes, and the interviewer knows that. So what are they actually watching for?
They are watching your process. Can you take something unbounded and scope it down to a few things that matter? Can you put a number on the scale before you pick a database? When you draw a box, can you say why it's there and what happens when it fails? A candidate who blurts "we'll use Kafka and Cassandra" in the first two minutes has shown nothing except that they know two product names. A candidate who calmly narrows the problem, sizes it, and builds up to those choices has shown they can do the actual job.
The spine, step by step#
Here is the whole procedure. Run it top to bottom on any prompt. Each step feeds the next: your requirements set your scale, your scale sizes your storage, your storage shapes your design, and your design exposes the bottleneck you'll deep-dive. Say each step out loud as you do it — the interviewer is scoring the reasoning, not the whiteboard.
- Clarify functional requirements. Ask what the system must do, then scope it down to the two or three core features you can actually design in the time. For "Design Twitter," that might be: post a tweet, follow a user, and see a home timeline. Say the rest is out of scope out loud ("I'll skip search, ads, and DMs for now") so the interviewer can redirect you if they wanted one of them.
- Nail down non-functional requirements. These are the qualities, not the features: expected scale (how many users, how many requests), latency target (a home timeline should load in under ~200 ms), availability (is brief downtime OK, or must it stay up), consistency (is it fine if a follower sees a tweet a second late), and durability (can you ever lose a posted tweet). Pick concrete targets — they drive every later choice.
- Do a back-of-envelope estimate. Turn scale into numbers you'll actually use. Start from daily active users, derive read and write queries per second (QPS), then storage per year, bandwidth, and cache size. For 100M daily users each reading their timeline a few times a day, that's a few thousand reads per second on average — call it tens of thousands at peak. That single number decides whether one database is even plausible.
- Design the API. Write the handful of endpoints the features imply — the contract between client and server. For Twitter: postTweet(userId, text), getTimeline(userId, page), followUser(userId, targetId). Keep it small. The API is where you pin down exactly what the system promises before you build anything behind it.
- Design the data model. Name the core entities and their relationships — User, Tweet, Follow — and let that shape imply a storage choice. A follow graph is relationships; a timeline is a time-ordered list. The data model is where you first commit to SQL versus NoSQL, and you should say why.
- Draw the high-level design. Now the boxes and arrows: client, load balancer, application servers, databases, caches, queues. Trace the happy path end to end for one core action — "a user posts a tweet, here's every hop it takes to reach a follower's timeline." This is the picture the rest of the interview builds on.
- Deep-dive a component. The interviewer will pick one part — often the hardest — and ask you to go deep. For Twitter it's usually timeline generation: do you build each timeline when it's read (fan-out on read) or push each tweet into follower timelines when it's written (fan-out on write)? Go into the mechanism, the data structures, the tradeoffs.
- Identify bottlenecks and tradeoffs. Step back and attack your own design. Where's the hot spot? What happens at a celebrity with 100M followers? Answer the classic prompt: "scale it 10× — what breaks first?" Naming your design's weak point before the interviewer does is one of the strongest signals you can send.
| # | Step | You produce | The question it answers |
|---|---|---|---|
| 1 | Functional requirements | 2–3 scoped features | What does it do? |
| 2 | Non-functional requirements | Scale, latency, availability, consistency targets | How well must it do it? |
| 3 | Back-of-envelope estimate | QPS, storage/year, bandwidth, cache size | How big is it? |
| 4 | API design | A few endpoint signatures | What does it promise callers? |
| 5 | Data model | Entities + storage choice | How is data shaped and stored? |
| 6 | High-level design | Boxes-and-arrows, happy path | How does it fit together? |
| 7 | Deep dive | One component, in depth | How does the hard part work? |
| 8 | Bottlenecks & tradeoffs | Weak points + 10× answer | Where does it break? |
PredictThe interviewer says "Design Twitter." What is your very first move — and what must you NOT do?
Hint: Which step is #1 on the spine — and which step's output are you tempted to skip to?
Your first move is step 1: clarify and scope the functional requirements. Ask what the core use cases are, then propose narrowing to two or three you can actually design — for example, post a tweet, follow a user, and view a home timeline — and say the rest is out of scope so the interviewer can redirect you. What you must NOT do is jump to a solution: naming databases, queues, or an architecture in the first two minutes. Picking Cassandra before you know the read/write ratio, the scale, or even which features you're building is the single most common way strong candidates torpedo themselves. Requirements first, always. The design has to be forced by the requirements, and you can't justify a choice you made before you knew the problem.
Pacing the 45 minutes#
Knowing the eight steps isn't enough — the hard part is spending your minutes well. A typical loop is about 45 minutes, and roughly a third of a session is lost by candidates who let the early steps eat the clock. Here's a budget that leaves room for the parts that actually earn points.
| Steps | Rough time | Notes |
|---|---|---|
| 1–2 Requirements (functional + non-functional) | ~5–8 min | Scope fast; don't interrogate every edge case |
| 3 Estimation | ~5 min | One or two numbers that change a decision, not a spreadsheet |
| 4–5 API + data model | ~5–8 min | A few endpoints, a few entities — keep it tight |
| 6 High-level design | ~10 min | The core diagram and the happy path |
| 7 Deep dive | ~10–12 min | This is where seniority shows — protect this time |
| 8 Bottlenecks + wrap-up | ~5 min | The 10× question and your own critique |
The two places candidates blow the budget are predictable. The first is over-clarifying: spending eight minutes asking about every feature and edge case, treating requirements like a requirements-gathering meeting instead of a two-minute scoping. The second is premature depth: getting to the high-level diagram and immediately rabbit-holing into the exact database schema or a caching detail, so the interviewer never sees you cover the whole system. The deep dive (step 7) is where senior signal lives, so the earlier steps exist to get you there with time to spare — not to be the show themselves. Watch the clock, and if you're behind, say "in the interest of time, let me move to the design" out loud. Managing your own time is itself a signal.
Breadth vs depth, driving vs waiting#
Two tensions run through the whole interview, and how you handle them separates a mid-level pass from a senior one.
- Breadth vs depth: covering the whole system versus going deep on one part. You need both, in order. Get a complete-enough high-level design on the board first (breadth), so the interviewer sees you can architect the full thing, then go deep on the component that matters (depth). All breadth and you look shallow; all depth and you look like you can't see the system. The spine sequences this for you — breadth is step 6, depth is step 7.
- Driving vs waiting: leading the design versus waiting to be told what to do. Interviewers want a candidate who drives — who proposes the next step, makes a call, and moves — not one who asks "what should I do now" at every turn. But driving isn't ignoring them. When they steer ("let's talk about the timeline"), follow immediately; that redirect is them telling you where the points are. Drive the process, take their turns on which component.
- High-level vs zoom-in: when to stay abstract and when to get concrete. Stay high-level while you're laying out the system — boxes and arrows, no schema yet. Zoom in only when you reach the deep dive, or when the interviewer asks. Zooming too early (schema-first) is the classic premature-depth trap; staying too abstract when they've asked for the mechanism reads as hand-waving.
The meta-skill under all three is narrating your tradeoffs out loud. Every real design choice has a cost, and saying "I'll use fan-out on write for fast reads, but it costs write amplification — one post becomes a write to every follower's timeline — for users with many followers" shows exactly the judgment the interview is built to find. A choice stated without its cost looks like a guess. A choice stated with its cost looks like engineering.
The spine vs winging it — and other named frameworks#
| Winging it | The spine | |
|---|---|---|
| First move | Name a technology | Scope the requirements |
| Coverage | Deep in one corner, gaps elsewhere | Whole system, then one deep dive |
| Numbers | Asserted or skipped | Derived from DAU |
| When stuck | Freeze or ramble | Next step is always defined |
| What it signals | Knows some product names | Can actually scope and design |
You'll see this same procedure sold under several names, and it's worth knowing they're the same thing so you don't think you have to learn four of them. Alex Xu's "System Design Interview" frames it as a four-step method — understand the problem and scope, propose a high-level design, deep-dive, then wrap up — which is the spine grouped into four phases. "RESHADED" is a mnemonic (Requirements, Estimation, Storage schema, High-level design, API, Detailed design, Evaluation, Distinctive features) that spells out the same steps. Grokking the System Design Interview walks the same arc across its worked problems. They differ in labels and granularity, not in substance: clarify, size, sketch the API and data, draw the system, go deep, then critique. Learn one spine cold and you can map any prompt or any book onto it. Memorizing all four gives you nothing extra.
PredictYou've practiced with Alex Xu's 4-step method, but the interviewer's company is known to use a "RESHADED"-style rubric. Do you need to relearn the framework?
Hint: Do the two frameworks ask for different work, or the same work with different names?
No. They're the same spine with different labels. Alex Xu's four steps (scope, high-level design, deep dive, wrap-up) and RESHADED (Requirements, Estimation, Storage schema, High-level design, API, Detailed design, Evaluation, Distinctive features) both walk the identical arc: understand and scope the problem, size it, sketch the API and data model, draw the high-level design, deep-dive a component, and evaluate for bottlenecks. RESHADED just breaks the same work into more named buckets. If you can run the eight-step spine fluently, you already satisfy any of these rubrics — the interviewer is scoring whether you scoped, sized, designed, went deep, and critiqued, not whether you recited their acronym. Pick one framework, internalize it until it's automatic under pressure, and adapt the labels on the fly.
The spine on three real prompts
The point of one spine is that it maps onto every prompt. Here's the same eight steps sketched across three classics — notice how only the nouns change.
- Design a URL shortener. Functional: shorten a long URL, redirect a short code to it. Non-functional: read-heavy (many redirects per shorten), redirects must be fast (~10s of ms) and highly available. Estimate: reads dominate writes maybe 100:1, so size the read path first. API: createShort(url) and GET /{code}. Data model: a code-to-URL mapping — a key-value store fits. Design: a write path that generates a unique short code, a read path that's mostly cache hits. Deep dive: how you generate short, unique, non-guessable codes (counter + base62, or a hash). Bottleneck: the redirect hot path — cache it hard; the code generator must never collide.
- Design a news feed. Functional: post, follow, and view a ranked home feed. Non-functional: feed loads fast (~200 ms), a slightly stale feed is fine (relaxed consistency). Estimate: reads vastly outnumber writes. API: postContent, getFeed. Data model: users, posts, a follow graph. Design: the classic fan-out choice. Deep dive: fan-out on write (push each post into follower feeds — fast reads, heavy writes) vs fan-out on read (build the feed at read time — cheap writes, slow reads), and the hybrid that handles celebrities. Bottleneck: a user with tens of millions of followers breaks pure fan-out-on-write.
- Design a chat system. Functional: one-to-one messaging, delivery and read receipts, online presence. Non-functional: low latency, messages must never be lost (durability), delivered in order. Estimate: connection count and messages per second drive the design. API: sendMessage, plus a persistent connection for pushes. Data model: messages keyed by conversation, ordered. Design: clients hold a long-lived WebSocket to a connection server; a message is persisted, then pushed to the recipient's connection. Deep dive: how the connection server routes a message to wherever the recipient is connected. Bottleneck: fan-out to large group chats, and handling users who are offline.
Pitfalls & gotchas
I jumped straight to "we'll use Cassandra and Kafka." What's wrong with that?
You named a solution before you had a problem. Until you've scoped the features, sized the scale, and shaped the data, a technology choice is a guess — and the interviewer can't tell whether you understand it or just recognize the name. Worse, you've boxed yourself in: if your later estimate shows the workload is read-heavy and tiny, Cassandra was the wrong call and now you have to unwind it. Always let the requirements force the choice, then name the tech with a reason attached.
I said "about a million requests per second" — the interviewer asked where that came from and I froze. How do I avoid that?
Never quote a number you didn't derive in front of them. The value of the back-of-envelope step isn't the final figure — it's showing the chain: daily active users, times reads per user per day, divided by ~86,400 seconds, gives reads per second. Walk that chain out loud, even roughly. A derived "roughly 200,000 reads per second" beats a confident "a million" that you can't defend, because the interviewer is testing whether you can reason about scale, not whether you memorized a stat.
I designed for 500 million users and it impressed nobody. Why?
Because you designed for scale you never justified. Sharding, multi-region replication, and elaborate caching are only impressive when the numbers demand them. If your estimate showed modest traffic, a huge distributed architecture is over-engineering, and interviewers read it as inability to match the solution to the problem. Let step 2 and step 3 set the scale, then build exactly what that scale needs — no more. "It's small enough for a single primary database" is a strong, senior answer when it's true.
I went quiet while I was thinking and the interviewer moved on. What should I have done?
Think out loud. Silence is the one thing an interviewer can't score — they can't see your reasoning, and a long pause reads as being stuck. Narrate even the uncertainty: "I'm weighing whether to fan out on write or on read; let me think about the read-versus-write ratio." That turns a dead pause into visible reasoning, and it often prompts a helpful nudge. The interview is a conversation about your process, so make the process audible.
I ran out of time before the deep dive. How do I protect it?
The deep dive is where senior signal lives, so budget backward from it. Keep requirements to a couple of minutes, keep estimation to the one or two numbers that change a decision, and don't polish the high-level diagram — get it good enough and move. If you feel the clock slipping, say "in the interest of time, let me get to the core of the design." Reaching the deep dive with time to reason beats a perfectly clarified requirements section and no design.
QuizA candidate spends 15 minutes meticulously clarifying every feature and edge case, then has to rush the high-level design and never reaches the deep dive. What's the core mistake?
- They didn't clarify enough — more requirements detail is always better.
- They mismanaged the time budget: over-clarifying starved the steps (design + deep dive) where the real signal is.
- They should have started coding sooner.
- Requirements don't matter; they should have skipped step 1.
Show answer
They mismanaged the time budget: over-clarifying starved the steps (design + deep dive) where the real signal is. — The mistake is pacing, not effort. Requirements clarification is meant to be a tight two-to-three-minute scoping pass — narrow to the core features and move. Spending 15 minutes there is over-clarifying, and it starves the two steps that actually demonstrate seniority: the high-level design and especially the deep dive. Interviewers score whether you can architect a system and reason deeply about its hard part, and this candidate never got to show either. The other options are wrong: requirements do matter (skipping step 1 is the opposite failure), and a system-design interview is about architecture, not writing code. The fix is a clock-aware budget that protects the back half of the session.
In the room: the checklist
Run this checklist in order, out loud. Each step doubles as a seniority signal — the checklist below pairs the move with what it tells the interviewer about you.
- Scope the features first (step 1). Narrowing an unbounded prompt to two or three core features signals you can manage scope under ambiguity — the first thing a senior engineer does on any real project.
- State concrete non-functional targets (step 2). Saying "~200 ms timeline load, availability over strict consistency" signals you know that scale, latency, and consistency drive the design, not the other way around.
- Derive your numbers out loud (step 3). Walking DAU → QPS → storage signals you reason about scale instead of reciting it, and it's the number every later choice hangs on.
- Pin the API and data model before the boxes (steps 4–5). Committing to a contract and an entity shape first signals disciplined, contract-driven thinking rather than drawing infrastructure for its own sake.
- Trace the happy path end to end (step 6). Following one action through every hop signals you see the whole system, not a bag of disconnected components.
- Go deep where they point, with tradeoffs (step 7). Choosing fan-out on write vs read and naming each cost is the clearest seniority signal in the whole interview — depth plus judgment.
- Critique your own design (step 8). Answering "scale it 10× — what breaks first?" before you're pushed signals you can find failure modes, which is most of what senior engineering actually is.
The through-line: drive the process, think out loud, let numbers force choices, and name the cost of every decision. That's what separates "knows some architectures" from "can design a system," and it's exactly what the spine is built to make visible.
PredictYou've drawn a clean high-level design and the interviewer asks: "Now scale it 10× — what breaks first?" What makes a strong answer?
Hint: Do you defend the design, or hunt for the component that saturates first — and then fix it?
A strong answer doesn't defend the design — it attacks it. Walk your own diagram and find the component that saturates first under 10× load, and be specific about why. For a news feed, that's usually the fan-out on write: at 10× the celebrity users with tens of millions of followers make each post a write to tens of millions of timelines, and that write amplification is the first thing to fall over. Then propose the mitigation: a hybrid that fans out on write for normal users but computes celebrity posts at read time. The pattern is always the same — name the specific bottleneck (a hot shard, a single-writer database, a queue that backs up), explain the mechanism that breaks it, and give a concrete fix with its own tradeoff. Finding your design's weak point before the interviewer does is the single strongest signal you can send, because spotting failure modes is most of what senior engineering is.
References
- System Design Interview — An Insider's Guide, Vol. 1 & 2 (Alex Xu) — The four-step framework and worked problems the spine is drawn from.
- Grokking the Modern System Design Interview (Educative) — The same arc walked across a large set of classic prompts.
- System Design Primer (GitHub) — A free, comprehensive reference for the estimation, storage, and design steps.
- Google — Site Reliability Engineering (free book) — How real systems set availability, latency, and durability targets — the non-functional step, in production.
- Latency Numbers Every Programmer Should Know — The reference figures behind a credible back-of-envelope estimate.