What a system design interview actually tests
Walk into a 45-minute design round knowing the four things being scored, the time budget for each, and the answers that quietly lose points.
A system design interview is 45 to 60 minutes, one deliberately underspecified prompt, and a shared surface — a whiteboard, or a collaborative doc when remote. "Design a URL shortener." "Design a news feed." There is no test suite and no correct answer waiting at the end. The interviewer is scoring four things, and only one is what most candidates prepare for.
The four things being scored
Problem navigation. Do you scope before you design? The prompt omits the numbers, the features, and the service levels on purpose, and a candidate who starts drawing boxes in minute two has failed this axis before saying anything technically wrong. The fix is to spend the first eight minutes turning "design a news feed" into "10 million daily active users, roughly 100 reads per write, feed load under 200 ms at p99" — see functional vs non-functional requirements for how to split those questions.
Technical judgment. Does every choice have a reason attached? Not "we will use Redis" but "a cache in front of Postgres, because at 1,000 QPS peak with a 95% hit rate the database sees 50 QPS instead of 1,000, and one commodity Postgres box tops out around 5,000 simple QPS."
Depth. Can you go three levels down on at least one component? Level one is "add a cache". Level two is "cache-aside, 60-second TTL, invalidate on write". Level three is "on a cold key, 500 concurrent requests miss and stampede the database, so we take a per-key lock and let one populate while the rest wait". Most candidates stop at level one on eight components; that scores worse than level three on one.
Communication. Does the interviewer know what you are thinking? Silence while you work something out reads exactly like silence while you are stuck. Both score as stuck.
The shape of the hour
A 60-minute slot is about 50 minutes of working time once introductions and your own questions are removed. A workable budget: 8 minutes scoping, 5 estimating, 12 on the high-level design, 15 in one deep dive, 10 on bottlenecks. If you are 20 minutes in and have not written a number down, you are behind.
The dotted edges matter more than the solid ones: that is the interviewer redirecting you, the most valuable signal in the room.
Estimation is the load-bearing part
Numbers convert an opinion into a decision. The arithmetic is crude, and crude is fine as long as it is shown. Take 1 million daily active users at 20 requests a day:
1,000,000 DAU x 20 req/day = 20,000,000 req/day
20,000,000 / 86,400 s ~= 230 QPS average
230 QPS x 4 (peak factor) ~= 1,000 QPS peak
Storage, if each request writes a 1 KB event kept for 90 days:
20,000,000 x 1 KB = 20 GB/day
20 GB x 90 days = 1.8 TB
Two conclusions follow, both worth points. 1,000 QPS peak sits under the roughly 5,000 simple QPS a single commodity Postgres box handles, so the honest answer to "do we shard?" is "not yet, and here is the number that would change my mind." And 1.8 TB fits on one machine's disk, so a distributed store is not justified either — the SQL vs NoSQL choice here is decided by access patterns, not by volume.
Candidates who skip this step end up sharding a database that a laptop could serve.
The seniority bar, concretely
The gap between a junior and a senior answer is mechanical enough to rehearse.
A junior candidate names components: "load balancer in front, then app servers, then a database, and a cache."
A senior candidate names the component, the alternative they rejected, and the number that decided it: "I will put a cache in front of the database. The alternative is read replicas, which I am rejecting here because replication lag breaks read-your-writes — the user posts a comment, the next read hits a lagging follower, and their own comment disappears. If the hit rate falls below about 80% I would revisit, because at 1,000 QPS that leaves 200 QPS on the primary and I have budget to 5,000."
Same diagram. Different hire decision. Three parts: the choice, the rejected alternative, the number.
Underneath all four axes is one question the interviewer is actually answering: would I want this person designing a system I have to operate at 3am? That is why unjustified choices score so badly. A design you cannot explain is a design nobody can debug under pressure.
It is a conversation, not a monologue
The interviewer is not a silent grader. When they say "interesting — what happens if that queue backs up?", they are not curious. They have seen the failure mode you walked past and are handing you the points. Ignoring a hint twice is close to fatal: it reads as either not listening or not able to change your mind, both disqualifying on the 3am test.
Narrate the plan: "I am going to leave the search path aside and go deep on the write path, because that is where the consistency problem is." Now a redirect costs ten seconds instead of ten minutes.
Wrong answers exist
There is no single correct design, but there are clearly wrong ones. Three reliably lose the round:
- Unjustified choices. Naming a technology with no reason attached. "Kafka" is not an argument.
- No numbers anywhere. Every scaling claim is then an assertion, and the interviewer cannot tell whether you know or are guessing.
- Designing for 100x the stated scale. The prompt said 1 million users. Multi-region deployment with cross-region consensus is not impressive at 230 QPS, it is a signal you cannot size a system. Ask about growth, then scale the axis that the number demands.
What is not tested
Memorised architectures. Reciting how a company built its feed in 2015 scores nothing without the constraints that forced it.
Vendor product names. Nobody cares whether you say SQS or Pub/Sub. "A durable queue with at-least-once delivery, so consumers must be idempotent because duplicates will arrive" is the answer; the brand is a footnote.
Writing code. You may write a schema, a cache key, or an API signature, never a function body. Start coding and you burn the deep-dive budget on the one thing not being scored.
In an interview
The round tests whether you can take an ambiguous problem, constrain it with numbers, choose under those constraints, and defend the choice out loud.
Open with scope, not architecture: "Before I draw anything — what scale, read-heavy or write-heavy, and what latency target?" Then estimate out loud, design, and volunteer your own deep dive: "The interesting part is fan-out on write. Let me go into that unless you would rather see the read path."
The mistake that loses points: treating a hint as an interruption. When you hear "would that still work at 10x?", stop, engage, and change the design if the number says so. Defending a design against a correct objection is worse than having drawn the wrong design in the first place.
Check yourself
The prompt is 5 million DAU, 10 requests per user per day, read-heavy. Do you shard the database in your first design? Show the number that decides it.
5,000,000 x 10 = 50,000,000 req/day. Divided by 86,400 s that is roughly 580 QPS average, around 2,300 QPS at a 4x peak — under the roughly 5,000 simple QPS one commodity Postgres box handles. So no: one primary, plus a cache for the read-heavy path. State the trigger: "I would shard when sustained peak crosses about 4,000 QPS, or when the working set stops fitting in RAM."
Twenty minutes in, the interviewer asks "what happens if the cache goes down?" You had planned to spend the next fifteen minutes on the API schema. What do you do?
Abandon the schema. The question is a hint that cold-start behaviour is what gets scored. Answer it directly: with an empty cache all 2,300 QPS lands on a database rated for 5,000 — survivable — but a stampede on hot keys multiplies that, so per-key locking or request coalescing goes in. The schema was never going to score depth points; this does.
You want to serve reads from followers instead of a cache. What single consequence must you name before the interviewer names it for you?
Replication lag breaks read-your-writes: a user updates their profile, the next read hits a follower that has not caught up, and the change appears to vanish. Naming it first — and routing that user's reads to the leader for a few seconds after a write — is the seniority difference described above. See consistency models.