The shape of the hour
A system design interview is usually 45 minutes with 35 of real design time. The single most common failure isn't a missing component — it's spending twenty minutes on requirements and never reaching a deep dive. Decide the time budget before you walk in, and keep a visible clock.
Every walkthrough on this site follows the same four phases. Interviewers are trained around this shape, so following it makes you easy to score — and easy to score high.
- MIN 0–5
Requirements & scope
Agree on 4-6 functional requirements and put numbers on the non-functional ones: users, reads vs writes, latency targets, consistency needs. End by saying what you are explicitly not building.
- MIN 5–10
Estimates, API, data model
One line each: QPS, storage, bandwidth. Then the 3-5 endpoints and the core entities. Don't linger — these exist to justify decisions you make later.
- MIN 10–20
High-level design
Draw the boxes that satisfy every functional requirement, and walk one request through the diagram out loud. Resist detail here; breadth first.
- MIN 20–35
Deep dives
Pick the two or three hardest problems in your own design and attack them before the interviewer does. This is where hire/no-hire is decided.
- MIN 35–40
Wrap
Bottlenecks, failure modes, what you'd do with another month. One minute, unprompted.
Phase 1 — requirements that set your level
Functional requirements are a negotiation, not a quiz. Propose the core set yourself, offer the cut list, and get a nod. Interviewers score ownership of scope — waiting to be told what to build reads as mid-level.
Non-functional requirements are where the design actually comes from. "Highly available" is noise; "99.99% available, feed loads under 200 ms at p99, eventual consistency is fine for likes but not for payments" is a design brief.
- Always classify the workload first: read-heavy, write-heavy, or fan-out — it decides your caching, your database and your queues.
- Name the consistency requirement per feature, not per system. Likes can be eventual; seat inventory cannot.
- State availability as a number and connect it to design: 99.99% means no single point of failure, which means replication and failover you must actually draw.
For scope I'd take shortening, redirection and basic analytics, and explicitly drop custom aliases and user accounts — happy to add them back if you want them. The numbers that matter: this is read-heavy, maybe 100 redirects for every write, and the redirect path has to stay under 100 ms.
Phase 2 — back-of-envelope without the spiral
Estimates exist to make one or two design decisions defensible — do we need sharding, do we need a cache, does this fit in memory. Two minutes, rounded numbers, move on. Precision here is a negative signal: it says you don't know what the numbers are for.
| Rule | Value | Use it for |
|---|---|---|
| Requests per day → QPS | 1M/day ≈ 12 QPS | Any traffic conversion. 100M/day ≈ 1,200 QPS; peak ≈ 2-5× average. |
| Seconds per day | ~86,400 ≈ 100k | Round to 10⁵ and division becomes mental arithmetic. |
| Powers of two | 2¹⁰ ≈ 10³ | KB→MB→GB→TB→PB, each ×1,000. |
| One char / one int | 1 B / 4 B | Row-size estimates: a 500 B row × 100M rows ≈ 50 GB — fits on one box. |
| Daily active fraction | DAU ≈ 10-20% of MAU | Scale user counts honestly instead of designing for all registered users. |
| 80/20 rule | 20% of data serves 80% of reads | Sizing caches: cache 20% of hot data, get most of the hit rate. |
Latency numbers to have loaded
You don't recite this table — you use it. When you say "that's a cross-region hop, 100 milliseconds, so we replicate reads locally", the table is doing its job.
| Operation | Latency | Compare |
|---|---|---|
| L1 cache reference | ~1 ns | The unit everything else is measured in |
| Main memory reference | ~100 ns | 100× L1 |
| Read 1 MB sequentially from memory | ~10 µs | Memory is the fastest 'disk' you have |
| SSD random read | ~100 µs | 1,000× memory reference |
| Read 1 MB sequentially from SSD | ~1 ms | Sequential beats random, always |
| Round trip inside one datacenter | ~0.5 ms | Microservice hop budget |
| Read 1 MB sequentially from spinning disk | ~5-10 ms | Why cold storage is cold |
| Round trip same continent | ~30-50 ms | Region-to-region replication lag floor |
| Round trip across the world | ~150 ms | Why CDNs and multi-region exist |
- Reads from memory are microseconds, SSD sub-millisecond, cross-region tenths of a second. Three tiers, six orders of magnitude.
- A page that makes 3 sequential cross-region calls has already spent ~450 ms — over any latency budget. Parallelise or move the data.
Phase 4 — deep dives are chosen, not suffered
After the high-level diagram, name the hard problems yourself: "The interesting parts here are the fan-out on write for celebrity accounts and keeping the unread counts consistent — which would you like me to go deep on?" You've shown judgement, offered control, and guaranteed the deep dive happens on ground you've prepared.
A good deep dive has a fixed anatomy: state the problem with a number, give two or three candidate approaches, pick one, and say what it costs. An answer without a cost isn't an answer — it's a hope.
- Senior signal: proposing the failure modes unprompted — what happens when the cache dies, when the queue backs up, when a region drops.
- Staff signal: connecting choices to organisational cost — "multi-leader replication solves this but I wouldn't pay its operational complexity at this team size".
- Universal signal: changing your mind cleanly when the interviewer adds a constraint. Defensiveness fails loops more than wrong answers do.
What each level is scored on
The same question is asked at every level; the bar moves, not the prompt.
| Level | Expected | Typical miss |
|---|---|---|
| Mid (L4/E4) | Complete working design with guidance; sensible components; answers deep-dive questions when steered there | Needs the interviewer to drive; hand-waves data model |
| Senior (L5/E5) | Drives the whole session; quantified trade-offs; 2-3 self-selected deep dives; failure modes unprompted | Breadth without depth — never lands a deep dive |
| Staff (L6/E6) | Shapes the problem itself; challenges requirements; evolution story (v1 → 10× → 100×); cost and operational awareness | Over-engineering the first version to look impressive |
The seven ways candidates fail
Interviewers see the same failure modes weekly. All seven are avoidable with the playbook above.
- Skipping requirements and drawing boxes at minute two — the design ends up solving a different question than the one asked.
- Buzzword architecture — dropping Kafka, Cassandra and Kubernetes into the diagram without saying what problem each one solves here.
- Estimation theatre — five minutes of precise arithmetic that never influences a single decision.
- One-database-fits-all — or its mirror image, a different exotic store for every table.
- Never going deep — a beautiful high-level diagram and 15 minutes of silence where the deep dive should be.
- Ignoring the interviewer's hints — a nudge toward a topic is the rubric leaking; take it.
- No failure story — a design where nothing ever crashes, times out, or retries is a design that has never met production.