Blog
Why You Failed The System Design Interview
You failed system design interview because you drew load balancer, cache, database, and queue like sacred icons. Then you stopped thinking.
Boxes are not design. Trade-offs are design.
Buzzword Architecture
Candidate says: “We add Redis, Kafka, Kubernetes, CDN, and microservices.”
Interviewer asks: why?
Silence.
This is not seniority. This is shopping list.
Start With Requirements
Ask traffic, read/write ratio, consistency needs, data size, latency target, failure tolerance, compliance constraints, and team size.
Design for constraints, not for whiteboard beauty.
Discuss Data First
What is source of truth? How is data partitioned? Which queries dominate? What consistency is required?
Database choice is not fashion. It follows access pattern and correctness needs.
CAP Is Not Spell
Do not say “CAP theorem” and move on. Explain trade-off.
Example: for account balance, consistency beats availability for write path. For product catalog, stale read may be acceptable.
Now you are designing, not reciting.
Latency Versus Throughput
Batching improves throughput but adds latency. Caching reduces reads but creates invalidation problem. Async processing improves response time but adds eventual consistency and recovery complexity.
Every solution has invoice.
Operational Thinking
How do you deploy? Roll back? Observe? Reprocess failed messages? Handle duplicate events? Backfill data? Rotate secrets?
Seniors talk about system after diagram exists.
Final Rule
System design interview is not test of how many technologies you can name.
It is test of whether you can reason under ambiguity and make trade-offs explicit. Draw fewer boxes. Explain more consequences.