Most candidates fail the system design interview not because they don't know the technology, but because they don't know how to drive the conversation. They act like passengers, waiting for the interviewer to tell them what to do.
In this guide, we break down the brutal reality of what a senior engineering panel is actually looking for.
1. Requirement Gathering (The Trap)
Don't just nod when they say "Design Twitter." Ask about read/write ratios, peak traffic, and strict consistency vs. eventual consistency. If you don't establish these constraints, your architecture will be evaluated against invisible goalposts.
2. Back-of-the-Envelope Math (The Filter)
Nobody expects you to calculate the exact byte size of a JSON payload in your head. They want to see if you understand the order of magnitude. Are we dealing with 100 requests per second or 100,000? Are we storing 10GB of data or 10PB?
3. High-Level Design (The Skeleton)
Draw the big boxes. Load balancer, API Gateway, Application servers, Database, Cache. Don't dive into the weeds yet.
4. Deep Dive (The Crucible)
This is where you earn your offer. The interviewer will point to a box and say, "This is going to fail. How do we fix it?"
You need to talk about sharding, replication, consistent hashing, message queues, and rate limiting.
Conclusion
Stop memorizing system design templates. Start understanding the trade-offs. Why Cassandra over PostgreSQL? Why Redis over Memcached? If you can answer the "Why", you'll pass.