System Design Mistakes
The twelve habits that sink system design interviews, from skipping requirements to not driving, what each looks like to the interviewer, and the fix.
A candidate is asked to design an internal tool for booking meeting rooms in one office: 400 employees, maybe 50 bookings an hour. Forty minutes later the board holds a sharded database, a stream processor, three caches and a multi-region failover plan. The feedback says "no hire". Every box was something they understood well. None of it was needed, and they never asked how many people would use it.
Most candidates who fail do not fail on knowledge. They fail on habits, and each has a fix you can practise. Here are the twelve most common, grouped by when they happen.
Before you draw
1. Skipping requirements
Looks like: the prompt is read and the first box goes up. The interviewer now has no evidence you can scope a problem, and you have no facts to justify anything later. Fix: spend the first few minutes on features, scale and priorities, and write them where the interviewer can see. Requirements and scope has the questions.
2. Designing for scale you did not establish
Looks like the meeting-room story: sharding for a load one server handles. 50 bookings an hour is about one a minute. Fix: let the numbers decide. Say "this fits on one database with a replica; here is the number at which I'd shard." Showing you know when not to scale is a strong signal.
3. No numbers
Looks like: "it's a lot of traffic, so we'll need caching." Fix: a 3-minute estimate of peak requests a second, storage and one more figure that matters, each ending in a decision. See back-of-the-envelope estimation and the reference figures in numbers to know.
4. Reciting a memorised design
Looks like: the question is a chat app for a hospital's staff, and the answer is the consumer chat design from a video, with global fan-out and no word about message retention rules. Fix: start from this prompt's requirements. Reuse patterns, not whole answers, and say which requirement makes this one different.
While you design
5. Drawing in silence
The interviewer only scores what they hear. Fix: narrate each decision as you draw it, including rejected ones: "I considered a queue here, but the user needs the result, so it's a direct call."
6. Buzzword stacking
Looks like: "We'll put Kafka in front, Redis beside it, Cassandra behind, all on Kubernetes." Each name is a claim you can be asked to defend. Fix: name the category and the reason ("a durable log, because three consumers read the same events"), and add a component only when a requirement asks for it. Talking through trade-offs gives the sentence to use.
7. Going deep too early
Looks like: 15 minutes on the perfect ID scheme while the read path still does not reach a database. Fix: get a simple design working end to end by about minute 27 of 45, then go deep where the interviewer points.
8. Not driving
Looks like: finishing each part and waiting, "what should I do next?" Interviewers at mid level and above score whether you lead. Fix: say the plan at the start, and at each pause propose the next step: "The high-level design is done. The hard part is the hot-key problem, so I'd like to go there unless you'd rather see storage."
9. Ignoring failure
Looks like: a design that works only when every box is up. Fix: walk the boxes and say what happens when each one dies, with a number. Step through it below.
- db reads/s
- 300
1The normal read: 3,000 reads a second, 90% served by the cache, so the database sees 300.
- db reads/s
- 300
2"What if an app server dies?" Requests in flight on it fail and clients retry. Health checks remove it within seconds, and the others take its share because they hold no state.
- db reads/s
- 3,000
3"What if the cache dies?" Every read falls through: 3,000 a second on a database that normally sees 300. Say it, then the fix: cache replicas, and a limit on fall-through traffic.
- db reads/s
- 300 failing
4"What if the primary dies?" Writes and cache misses fail. Replication is asynchronous, so writes the replica had not received yet are lost. Say so plainly; do not claim zero loss.
- db reads/s
- 300
5The replica is promoted and writes resume after the failover, often tens of seconds. If losing even a second of writes is unacceptable, replicate synchronously to one copy and pay for it in write latency.
- db reads/s
- 300
6"And the load balancer?" Run two, with one taking over the shared address if the other stops answering. Every box now has an answer, which is what the interviewer was checking.
Under pressure
10. Defending a choice after a hint
"Is a database write on every click a problem?" is rarely a neutral question. Looks like: "No, databases are fast." Fix: assume a hint points at a flaw, say what breaks with a number, fix it.
11. Promising guarantees you cannot keep
Looks like: "the queue gives us exactly-once delivery." Over a network, a message can always be delivered twice when an acknowledgement is lost. What systems offer is at-least-once delivery plus an idempotent consumer, so a repeat has no extra effect: exactly-once processing. Fix: name the real guarantee and the mechanism. See idempotency and retries.
12. Hand-waving the hard part
Looks like: "the database handles the concurrency" for a seat booking, which is the one place the interviewer wanted depth. Fix: when you reach the part that makes this problem hard, slow down: name the race, show the rows, say which lock or condition prevents it.
| Option | Good at | Bad at | Pick it when |
|---|---|---|---|
| Keep going and hope | No time spent. | If the interviewer saw it too, they now think you did not. | Never for a real flaw. |
| Start the design over | A clean board. | Burns 10 minutes and the depth you were about to show. | Only if the flaw breaks the core requirement and it is before minute 15. |
| Name it and patch it Usual default | Shows self-review, which interviewers score, in under a minute. | The board gets a little messy. | Almost always. |
In the interview
Most of these mistakes have a sentence that prevents them. Practise these until they are automatic:
- Requirements: "Before I draw, a few questions on features and scale."
- Scale: "At 50 bookings an hour this is one small database. I'll note what would make me shard."
- Driving: "Next I'd go into the hard part, which here is double bookings."
- Failure: "Let me walk each box and say what happens when it dies."
- Self-review: "I just noticed a problem with what I drew. Here is the fix."
Design a meeting-room booking tool for our office.
Sure. I'll start with a global load balancer, then microservices for rooms, users and bookings, each with its own database, sharded by user id, and a stream for events.
Design a meeting-room booking tool for our office.
How many people and rooms, and is it one office? And is the main risk two people booking the same room at the same time?
One office, 400 people, 30 rooms. Yes, double bookings are the complaint today.
Then scale is small, about a booking a minute, so one service and one relational database with a replica. The interesting part is preventing overlapping bookings for a room. I'll spend most of our time there.
Follow-ups you should expect:
- "What if it grows to 100 offices?" Do the maths: 100 × 50 an hour is about 80 bookings a minute, still small. Say what you would watch.
- "What are you least sure about?" Name the weakest part of your design and how you would test it. Pretending there is none is a weak answer.
A design has a cache with a 90% hit rate in front of a database, and 3,000 reads a second at peak. The interviewer asks what happens when the cache dies. What load does the database see?
A candidate says their queue gives exactly-once delivery. What is the accurate version?
At minute 30 you realise your design lets two people book the same room. What is the best move?
What to practise next
See how expectations shift with seniority in What Changes by Level, then run a timed attempt from Mock Interview Practice and score yourself against this list.