System design
System design frightens people because it has no right answer. That is also what makes it learnable: you are being assessed on whether you can reason about a system you have never seen, out loud, with someone senior watching.
What to do
Learn the vocabulary properly
Load balancer, cache, queue, replica, shard, index, idempotency, eventual consistency. Interviewers listen for these words used correctly. Using one incorrectly is worse than not using it.
Always start with requirements
How many users, read-heavy or write-heavy, what latency, what may fail. Candidates who begin drawing boxes immediately lose marks in the first three minutes.
Study three real architectures until you could redraw them
A URL shortener, a news feed, and a chat system. Between them they cover storage choice, fan-out, caching, queues and consistency. Depth in three beats shallow familiarity with twenty.
Speak in trade-offs, never in product names
"I would put a queue here so writes survive a downstream outage, at the cost of eventual consistency" is a senior answer. "I would use Kafka" is not, on its own.
Practise the estimate
Rough numbers for storage, bandwidth and queries per second. You are not being graded on arithmetic; you are being graded on whether you know how big things are.
What goes wrong
- Designing for a scale nobody asked for. Ten thousand users does not need five data centres, and proposing them signals poor judgement.
- Naming technologies as a substitute for reasoning.
- Never mentioning failure. Every senior interviewer is waiting to hear what happens when a component dies.
- Refusing to commit. Explore options, then choose one and defend it.
Where to go next
Outside resources worth your time. We are not paid to list any of these, and each one is useful without paying for it.
Want someone to go through this with you?
Tell us what you are stuck on and we go looking for the right person.