System Design Interviews: A Four-Step Method with Real Numbers
How to scope, estimate, design and defend a system in 45 minutes, with back-of-the-envelope numbers, a worked URL shortener and the mistakes interviewers see most.
· 7 min read
The candidate had drawn eleven boxes in twelve minutes: load balancer, API gateway, three microservices, Kafka, Redis, Cassandra, a CDN, a search cluster and something labelled "ML". Then the interviewer asked how many writes per second the system had to handle, and there was no answer. The design was not wrong. It was unearned. Nothing on the board followed from a requirement or a number, so there was nothing to defend when the questions started.
That is the pattern behind most failed system design rounds, and it is fixable with a structure you rehearse until it is automatic. This guide walks through that structure, the arithmetic, a worked example, and the mistakes interviewers see every week. Keep the System Design Interview Framework open for the practice prompts and the topic reference.
What the round actually tests
There is no correct answer to "design a news feed", so the interviewer is scoring the path you take. In most loops the rubric boils down to four questions:
- Did you scope the problem? Functional requirements, non-functional requirements and scale, agreed before drawing.
- Is the high-level design sound? The main components, how data flows between them, and the core APIs and data model.
- Can you go deep? Pick one or two components and handle the details: schema, indexes, partitioning, failure cases, concurrency.
- Do you see trade-offs? Every cache, queue, replica and shard costs something. Senior candidates say what, unprompted.
The level you are interviewing for changes the weight. A mid-level candidate who produces a clean, working design with sensible numbers usually passes. A senior or staff candidate is expected to drive the conversation, spot the hard part of the problem early, and discuss operational concerns such as migrations, monitoring and failure modes.
The four steps, with timings
For a 45 minute round, this split works:
| Step | Time | What to produce |
|---|---|---|
| Requirements and estimates | 5 to 10 min | 3 to 5 core features, explicit non-goals, latency and availability targets, QPS and storage numbers |
| High-level design | 10 to 15 min | Boxes and arrows for the main path, core APIs, the data model |
| Detailed design | 15 to 20 min | One or two components in depth: schema, partition key, algorithms, failure handling |
| Scale and trade-offs | 5 to 10 min | Bottlenecks, what breaks at 10x, what you would monitor, what you chose not to do |
Say this structure out loud in the first minute. It tells the interviewer you will manage the time, and it gives them an easy way to redirect you ("let's skip ahead to the storage layer"). When they redirect, follow. The timings are a default, not a contract.
Back-of-the-envelope numbers
Estimates decide which components you need, so do them early and write them on the board. A handful of constants cover nearly every prompt:
- A day has 86,400 seconds. Round it to 100,000 for mental arithmetic.
- 1 million requests a day is about 12 per second on average. 100 million a day is about 1,160 per second.
- Peak traffic is commonly two to three times the average. Say which multiplier you assume.
- A 7-character Base62 code has 62⁷, about 3.5 trillion, possible values.
- Reading from memory takes on the order of hundreds of nanoseconds for a random access; a round trip within one data centre is on the order of half a millisecond; a cross-continent round trip is on the order of 100 milliseconds.
Round hard. The purpose is the order of magnitude: 40 writes per second fits on one database with room to spare, 40,000 does not. If you catch yourself computing 1,157.4, stop and say "about 1,200".
Worked example: a URL shortener
Take the URL shortener prompt from the practice tab. It is the usual warm-up, and it shows the whole method in miniature.
Requirements. Create a short link for a long URL; redirect on visit; optional custom alias; links expire after five years. Non-functional: redirects must be fast (under 50 ms server time) and highly available; creating links can be slightly slower. Out of scope: user accounts and detailed analytics.
Estimates. Assume 100 million new links a month and a 10:1 read to write ratio.
writes: 100,000,000 / (30 x 86,400) ≈ 40 per second (peak ~100)
reads: ≈ 400 per second (peak ~1,000)
links over 5 years: 100M x 12 x 5 = 6 billion
storage: 6B x ~500 bytes ≈ 3 TB
code space: 62^7 ≈ 3.5 trillion, so 7 characters is plenty
Those numbers change the conversation. This is not a big-scale problem in throughput. The interesting parts are generating unique codes without collisions and keeping redirects fast.
High-level design. A stateless API tier behind a load balancer; POST /links returns a code, GET /{code} returns a 301 or 302 redirect. A key-value or relational store keyed by code. A cache in front for hot links.
Detailed design. Pick code generation. Hashing the URL and truncating causes collisions you must detect and retry. A counter encoded in Base62 is collision-free but needs a distributed ID source, for example ranges of IDs handed out to each API server so they do not coordinate on every request. Discuss the trade-off: sequential codes are guessable, which matters if links are meant to be private.
Trade-offs. 301 redirects are cached by browsers, which cuts load but hides repeat visits from any click counting; 302 does the opposite. Say which you choose and why.
Building blocks to explain in two sentences
You do not need to know everything in the Advanced Topics tab, but you should be able to explain these clearly, including when not to use them:
- Caching patterns. Cache-aside is the default; write-through trades write latency for fresher reads. Name your invalidation strategy.
- Sharding. Pick a partition key that spreads load and keeps common queries on one shard. Celebrity users and hot keys break naive schemes.
- Replication. Read replicas scale reads but introduce replication lag; read-your-own-writes needs care.
- Queues. Decouple slow work from the request path. Delivery is usually at least once, so consumers must be idempotent.
- CAP and PACELC. During a network partition you choose consistency or availability; otherwise you trade latency against consistency. "Pick two of three" is the version interviewers push back on.
- Bloom filters. Answer "definitely not present" or "possibly present" in little memory, with false positives but no false negatives.
Common mistakes
Drawing before scoping. The opening story. If you are not sure what to ask, ask about users, the most important feature, read and write ratio, and consistency needs.
Skipping the numbers. Without them you cannot justify a cache or a shard, and the interviewer has to drag them out of you.
Going broad instead of deep. Ten components at one sentence each is a weaker signal than two components handled properly.
Name-dropping technology. "Use Kafka" is not a design. "Write events to a partitioned log keyed by user ID so each user's events stay ordered" is.
Presenting trade-offs as free. If you add a cache, mention staleness. If you denormalize, mention write amplification. If you go async, mention what the user sees before the work completes.
Defending a choice after being shown it fails. When the interviewer points out a hole, acknowledge it and adjust. Updating cleanly under pressure is part of what is being scored.
A practice plan for two to four weeks
Do one prompt every two or three days, alone first and then with a partner playing interviewer. Time each session to 45 minutes. After each, write down the numbers you used and one thing you would do differently. Draw the final design in the Diagram Tool; redrawing it the next day from memory is a quick check of whether you understood it.
Spread practice across prompts that stress different things: a feed (fan-out), a chat app (connections and delivery guarantees), a rate limiter (distributed counters), a ride-sharing service (geospatial indexing), and a video platform (storage and CDNs). Pair this with the Coding Interview Prep Checklist if your loop has coding rounds, and prepare stories for the behavioral round with the STAR answer builder. If you write design docs at work, the Design Document Generator uses the same requirements and trade-offs habits, which is good practice in itself.
Before your real interview, run one full mock with someone senior who will interrupt you. Interruptions are normal in this round, and practising recovery is worth more than another solo session.