Start here
System design interviews fail for one reason most of the time: candidates jump into solutions before understanding the problem. This guide gives you the framework, the habits, and the mental models to avoid that.
It is not a correct answer. There is no single correct design for a distributed system. Interviewers are watching how you think: whether you can navigate ambiguity, make reasoned trade-offs, and communicate decisions clearly.
The four things an interviewer is scoring you on, in roughly this order:
Problem scoping
Do you ask the right questions before drawing a single box?
Breadth of knowledge
Do you know the standard components and when to reach for each one?
Trade-off reasoning
Can you articulate why you chose X over Y, not just that you chose X?
Communication
Is the interviewer always clear on where you are and where you are going?
A candidate who designs a mediocre system while clearly explaining the trade-offs will outperform a candidate who designs a good system while narrating what they are drawing. Reasoning beats output.
Most system design interviews run 45 minutes. Use this structure to fill that time intentionally. Skipping phase 1 is the most common cause of failure.
Do not touch the whiteboard yet. Ask questions. The problem statement is always underspecified on purpose — the interviewer is watching whether you notice.
Functional requirements: what the system does
Non-functional requirements: how well the system does it
After requirements, state your assumptions out loud and get confirmation. "I am going to assume 10M DAU, mostly reads, with eventual consistency acceptable on the feed. Does that match what you have in mind?" This aligns expectations and shows you are collaborative.
Back-of-the-envelope math tells you what kind of system you need before you design it. Do not skip this — it drives every architectural decision.
Example: notification system, 100M notifications/day
100M / day = 100M / 86,400s ≈ 1,160 writes/second
Peak (10x average) ≈ 12,000 writes/second
Each notification payload ≈ 1 KB
Storage/day = 100M × 1KB = 100 GB/day
Storage/year = 100GB × 365 = ~36 TB
These numbers now tell you: you need a write-optimized storage solution, a queue to absorb 12k peak writes/sec, and a plan for 36TB of data in year one. You would not reach for SQLite. You would reach for Cassandra or DynamoDB.
Draw the major components first: clients, API layer, services, queues, databases, caches. Keep it at the box-and-arrow level. Name each component. Draw data flow arrows with a brief label ("writes notification events", "polls for status").
Then pick 2 or 3 areas and go deep. Do not try to cover everything. Let the interviewer steer if they want more depth somewhere specific.
Good deep dive candidates:
Step back and critique your own design. This is where strong candidates separate from average ones. Name the weakest point in the system and how you would address it with more time or a different constraint.
"The biggest risk in my design is the fan-out service becoming a bottleneck at peak. I would mitigate this by pre-computing fan-out lists for high-follower accounts during off-peak hours, and using a hybrid push/pull model for outliers."
Jumping to solutions
Immediately drawing a microservices diagram before asking a single question.
Spend the first 10 minutes only on requirements. The design flows from the constraints, not from pattern-matching to past problems.
Designing for infinite scale from the start
Proposing Kafka, Cassandra, and a CDN for a system with 1,000 users.
Design for the given scale. Know what breaks first and at what threshold you would add complexity. Over-engineering is a red flag.
Handwaving the database
"I will use a database here." Full stop.
State the choice, state why. 'PostgreSQL for user data because writes are low-volume and ACID guarantees matter for billing. Cassandra for the notification log because it is write-heavy and we can tolerate eventual consistency.'
Silent designing
Drawing for 5 minutes without saying a word.
Narrate every decision as you make it. If you are thinking, say what you are thinking. The interviewer cannot grade reasoning they cannot hear.
Ignoring failure modes
A design where every service works perfectly and no server ever fails.
Proactively mention: what happens when the queue is full? What if the push provider is down? What if a worker crashes mid-fan-out? Show you design for failure.
Getting stuck is normal. What matters is how you handle it.
When: You do not know which database to use
Ask yourself: read-heavy or write-heavy? Structured or unstructured? Need transactions? This flowchart almost always gets you to the right family of database.
When: You do not know how to handle scale
Name the bottleneck first. 'This API server will hit CPU limits at ~5k req/s. To go beyond that I would horizontal-scale behind a load balancer.' Naming the problem is already a good answer.
When: You have genuinely not seen the pattern before
Say so, then reason from first principles. 'I haven't built this before, but the problem looks similar to X because of Y. I would start with Z and see what breaks.' Honesty plus reasoning beats bluffing.
When: You are running out of time
Signal it. 'I want to keep moving — I will leave the monitoring and alerting design as a note and come back if we have time.' Controlling pace is a senior skill.
These are not buzzwords to drop — they are precise terms that communicate a specific concept efficiently. Use them when you mean them.
| Term | When to use it |
|---|---|
| Idempotent | An operation that produces the same result whether called once or ten times. Critical for retries. |
| At-least-once delivery | The queue delivers every message, but may deliver some twice. Acceptable when you can deduplicate downstream. |
| Head-of-line blocking | A slow item at the front of a queue blocks all items behind it. Reason to use multiple queues or priority lanes. |
| Fan-out | One event triggers writes to many destinations. The design challenge in notification systems, social feeds. |
| Back-pressure | When a downstream service signals 'slow down' to the upstream producer. Prevents cascading failure. |
| Hot partition | One shard getting disproportionate traffic due to a popular key. Design data models to avoid it. |
| Write-through / write-behind cache | Whether the cache is populated on write (through) or asynchronously (behind). Different consistency guarantees. |
Ready to practice?
Apply the framework on a real challenge. Fill in your design, submit for AI review.