ChannelPulse
What the round actually measures
A system design interview is forty-five minutes of design review conducted on a system that does not exist yet. This is the time budget that survives contact with a real interviewer, and the four signals your score is actually assembled from.
What you'll be able to do
- Spend the first eight minutes on requirements and scale, and know exactly what to write down during them
- Name the four things an interviewer scores, and which parts of the round each one is decided in
- State a non-functional requirement as a number rather than an adjective, so the rest of the design can be checked against it
- Choose your own deep dive instead of waiting to be assigned one
The single most common way to fail a system design round is to answer a question nobody asked. The prompt is four words — "design a news feed" — and it is not a specification. It is an invitation to write one. Candidates who treat it as a request for a diagram start drawing boxes at minute two, and by minute twenty they have a plausible architecture for a system whose requirements were never agreed. Everything after that is unfalsifiable: the interviewer cannot tell whether the design is good, because there is no statement of what good would mean.
The candidates who do well are boring for the first eight minutes. They ask about scale, they write down numbers, they say out loud which features they are not building. Only then does anything get drawn — and by then, every box on the whiteboard exists because some written requirement demanded it.
Seven minutes for the whole arc, which makes it the right thing to watch first — requirements, estimation, high-level design, deep dive, bottlenecks, wrap-up. Every section of this module expands one of these chapters, so use it as the map.
Jump to the part you need
Four signals, and where each one is decided
Published guidance from hiring companies converges on roughly the same breakdown, whatever the labels: can you scope a problem, can you reason quantitatively, do you know the mechanisms, and can you defend a choice. What matters for how you spend your time is that these are decided in different parts of the round, and one of them is decided almost entirely in the first ten minutes.
| Signal | Where it's won | How it's lost |
|---|---|---|
| Problem scoping | Minutes 0–8 | Drawing before agreeing what's in scope |
| Quantitative reasoning | Minutes 5–12 | "It'll be a lot of traffic" instead of a number |
| Mechanism knowledge | Minutes 12–35 | Naming a technology instead of the property you need from it |
| Trade-off defence | Whole round, tested at the end | Presenting one option as though no other existed |
The fourth is the one that separates a senior signal from a mid-level one, and it is not about knowing more. It is about the shape of your sentences. "I'll use Cassandra" is a mid-level answer even when Cassandra is right. "Writes are a hundred times rarer than reads here and each one is a small append keyed by user — that's a fit for a wide-column store, and I'd take Cassandra unless we need read-your-writes on the timeline, in which case the eventual consistency starts costing us" is the same decision with the reasoning left in.
The time budget
Forty-five minutes is the common length; some loops run sixty. The proportions matter more than the absolute numbers, so here is the budget as fractions of the round, with the 45-minute version in brackets.
| Phase | Share | 45-min | What exists at the end of it |
|---|---|---|---|
| 1. Functional requirements | 10% | 0–5 | A written list of the 3–4 features you're building, and what you're not |
| 2. Non-functional requirements & scale | 8% | 5–8 | Numbers: users, QPS, read:write ratio, payload size, latency target |
| 3. API & data model | 12% | 8–13 | The 3–5 endpoints and the core entities, with their keys |
| 4. High-level design | 28% | 13–25 | A diagram whose every box traces to a requirement |
| 5. Deep dive | 33% | 25–40 | One bottleneck, chosen by you, taken to real depth |
| 6. Failure modes & wrap-up | 9% | 40–45 | What breaks, what it degrades to, what you'd monitor |
Two things about this budget are worth defending when you feel the pull to skip them.
Phase 2 is not optional, and it is not a ritual. The numbers you produce are what make phases 4 and 5 decidable. Whether you need a cache, whether the data fits on one machine, whether you can afford a synchronous write path — every one of those is an arithmetic question, and you cannot answer any of them from an adjective. This is the whole subject of the next lesson.
Phase 5 is yours to choose. Weaker candidates wait to be told where to go deep, which turns the deep dive into an interrogation. Stronger ones finish the high-level design and say: "The interesting problem here is the fan-out on write for celebrity accounts — that's where this design falls over first, and I'd like to spend the rest of the time there unless you'd rather look somewhere else." You have now demonstrated that you know which part is hard, which is itself the signal, and you get to go deep on ground you know.
Turning adjectives into numbers
Phase 2 goes wrong in a specific, recognisable way: the candidate says "it should be highly available and low latency" and moves on. Neither of those is a requirement. Neither can be checked. Neither constrains a single later decision.
A non-functional requirement is only useful once it is a number attached to a percentile.
| Adjective | The version that constrains a design |
|---|---|
| "Low latency" | p99 under 200 ms for a feed read, measured server-side |
| "Highly available" | 99.9% for reads; writes may fail closed during a partition |
| "Scalable" | 100 M DAU, 5× headroom, no re-architecture inside two years |
| "Consistent" | A user must see their own post immediately; others may lag 5 s |
| "Durable" | No acknowledged write is ever lost; a 5 s replication window is fine |
Look at the last two. "A user must see their own post immediately; others may lag five seconds" is read-your-writes consistency with a bounded staleness allowance elsewhere, and it single-handedly decides several later arguments: it permits an asynchronous fan-out, it forbids serving that user's own timeline from a stale replica, and it tells you exactly which cache needs invalidating synchronously. One sentence in phase 2 has just paid for itself three times in phase 4.
A complete answer to the most-asked question in the format, at interview pace. Watch the first three chapters against the requirements pass below and compare them line by line — the requirements-and-schema section is over inside two minutes, which is the budget this lesson argues for.
Jump to the part you need
A worked requirements pass
Here is the whole of phases 1 and 2 for a prompt you have certainly seen, at the level of detail you should actually produce. It is short on purpose: eight minutes is not long, and the output is a page, not an essay.
1Agree the functional requirements, out loud, as a list▾
Prompt: design a URL shortener.
Say what you are building, in the smallest set of verbs that makes a product:
- A user submits a long URL and gets back a short one.
- Anyone who visits the short URL is redirected to the long one.
- The creator can see how many times their link was visited.
Then — and this is the half most people skip — say what you are not building, and invite correction:
Out of scope unless you'd like it: custom vanity slugs, link expiry, user accounts and auth, edit-after-create, and abuse/malware scanning. I'd call abuse scanning the one that would really exist in production, but I'll leave it out of the core design and come back to it if there's time.
That paragraph does three jobs. It bounds the round so you can finish. It shows you know what a real version of this contains. And it hands the interviewer a cheap way to steer, which they will often take — "actually, let's include expiry" is useful information you got for free.
2Get the scale, by asking for one number and deriving the rest▾
You need one anchor. Ask for it directly:
How many new links per day should I design for?
Suppose the answer is 100 million writes per day. You now derive everything else in front of them rather than asking six more questions:
- Reads are the point of a shortener, so assume a read:write ratio — 100:1 is the conventional starting figure for this system, and say that you're assuming it.
- 100 M writes/day is roughly 1,160 writes/second on average; 10 billion reads/day is roughly 116,000 reads/second.
- Multiply by a peak factor. Traffic is never flat; 2× is the smallest defensible number and 3× is safer for a consumer system with a daily rhythm.
- A stored record is small — the long URL dominates, call it 500 bytes with metadata. 100 M × 500 B is about 50 GB/day, so roughly 18 TB/year.
Next lesson does this arithmetic properly, with the powers of two written down. For now, notice what those four bullets bought you: you know reads dominate by two orders of magnitude (so the read path gets a cache and a CDN, and the write path can be simple), and you know a year of data does not fit comfortably on one node's memory but a hot subset easily does.
3State the non-functional requirements as numbers▾
- Redirects: p99 under 100 ms. This is a hop in someone else's page load, so it has to feel free.
- Availability: redirects 99.99% — a dead redirect breaks links that are already published, which is unrecoverable reputational damage. Creation can be 99.9%; a failed create is retryable.
- Consistency: a newly created link must work immediately for its creator. Click counts may lag by a minute — nobody makes a decision on a real-time counter.
- Durability: a short code must never be silently reassigned to a different URL.
Read that last set again and notice how asymmetric it is. Redirects are more available than creates, and analytics are allowed to be stale while the mapping is not. That asymmetry is the design. It tells you the redirect path should be cacheable and should not depend on the analytics path being up — which is why, in phase 4, click recording goes onto a queue instead of into the redirect's critical path.
Two habits that read as seniority
Trace every box back to a requirement. When you add a component, name the requirement that forced it: "reads are 100× writes and the working set is small, so a cache in front of the mapping lookup — that's what gets the p99 under 100 ms." A diagram where every box has a reason is a design. A diagram assembled from remembered diagrams is a recital, and interviewers can tell the difference immediately because they ask "why is that there?" and the recital has no answer.
Say what you would do differently at a tenth of the scale. "At 100 K links a day this is a single Postgres instance and a read replica, and I would not build any of the rest of this" demonstrates something a scaled design cannot: that you know the complexity has a price and you are choosing to pay it. Volunteering that is one of the strongest senior signals available in the round, and it takes ten seconds.
What to carry into the next lesson
The method is deliberately mechanical: agree the features, get the numbers, model the data, draw the design, pick the bottleneck, name the failure modes. The mechanical part is what frees your attention for the actual thinking.
Everything downstream of phase 2 depends on the arithmetic being right, and the arithmetic is where most candidates are least practised — not because it is hard, but because doing it out loud while someone watches is a skill of its own. That is the next lesson, and it is the one with the code you can run.