System design interview guide
How a system design round runs, what senior interviewers listen for, the eight-stage structure that works, and ten classic problems to practise.
The system design round is 45–60 minutes on one open-ended problem: design a URL shortener, a news feed, a chat service, a rate limiter. There is no single right architecture. The interviewer is grading how you scope, what you name, whether you make choices and defend them, and whether you can drive the conversation without being led.
It is also the round where seniority is decided. A mid-level candidate answers the interviewer’s questions well. A senior candidate anticipates them, states the numbers, and moves to the next stage before being asked.
What the round looks like
The prompt is short and deliberately vague. The first ten minutes are yours: ask about users, scale, read/write ratio, latency expectations, and consistency needs. Then you draw the core flow, define the API and data model, and only then talk about storage, caching, sharding, and replication. The last fifteen minutes are the interviewer probing: “what happens when this node dies”, “how do you handle a hot key”, “what if the two writes conflict”.
Interviewers tend to walk the problem in a fixed order. If you present in that same order, the conversation feels natural and you rarely get caught off guard.
What interviewers listen for
- Scoping with a number: “100 million URLs a month, 10:1 read to write, p99 under 100 ms” turns a vague prompt into a solvable one.
- A clean API and data model before any talk of scale. Boxes and arrows without a schema are a warning sign.
- Real component names: a specific database family, a specific queue, a specific cache, and why that one.
- Trade-offs in the form “X over Y because Z, accepting W”: consistency over availability, push over pull, SQL over NoSQL.
- Failure modes named before being asked: single points of failure, hot partitions, thundering herds, retries without idempotency.
- A sense of proportion. Do not shard a system that fits on one machine; do say when it would stop fitting.
- Driving the conversation: “Next I’d cover storage — unless you want to go deeper on the API first.”
How to structure an answer
Use eight stages in this order: requirements (functional plus the one scale number), API, data model, core components and flow, storage, scaling (caching, sharding, replication), failure modes and consistency, and observability and rollout. Spend two or three minutes per stage on the first pass and let the interviewer’s questions decide where to go deeper.
For an ML-flavoured design (a ranker, a recommender, fraud detection), the ladder changes: scope and objective, pipeline, data and labels, features, model, training, serving, evaluation. The discipline is the same — state the choice per stage, then expand where pushed.
Questions to practise
- Design a URL shortener. Then: how do you handle a link that goes viral?
- Design a rate limiter for a public API.
- Design the news feed for a social network.
- Design a one-to-one and group chat service with delivery guarantees.
- Design a notification system that fans out to email, push, and SMS.
- Design a distributed key-value cache.
- Design the matching system for a ride-hailing app.
- Design a file storage and sync service.
- Design search autocomplete for a large query log.
- Design a metrics and logging pipeline for thousands of services.