Until now, I've participated in all three sides of system design interviews. I've played the role of the candidate, the interviewer, and the observer. These experiences have taught me a few things about how to do better. And in this article, I want to write about that in detail.
Books
Like everyone else, I started this journey by reading books. Books are an excellent resource to start with, but they have their limitations. They teach you that concepts exist and show you how to use them through small, isolated examples. However, in a real interview setting, this knowledge often falls short.
Those who have actually designed large-scale systems in production know the truth: it is a highly complex process with many moving parts. Take designing a URL shortener, for example. The books will tell you roughly: "You’ll need a database here, a cache there, sharding over here..." and so on. But a real interview is dynamic. The architecture shown in books is rarely the optimal answer for the specific constraints at hand. Starting today, we need to get comfortable saying and hearing"it depends."
The Real Interview
Imagine you are designing a system exactly as the books taught you, and suddenly you are asked: "How will you handle 1 million requests per second?" How do you answer that? How does your current design prove, with evidence, that it can handle that load? What numbers back up your answer? How does your design change?
Fortunately, no one actually shocked me with this question during an interview. However, I discussed this scenario with a brilliant engineer friend of mine. It was only after going home and really thinking about it that I understood the fundamental flaw in the books.
Initially, you try to follow patterns. Your brain automatically preps the answer: "We need a cache here because..." But then you get hit with another curveball: "If 60% of incoming requests miss the cache, is that cache still useful to the system, or is it just adding latency and operational overhead?" You freeze. The hope of answering fades away.
Math and Numbers
To answer these questions, you need to change your design. To change your design, you need to change your way of thinking. And to change your way of thinking, you need to change your approach to the interview entirely. This is where "Mathematics" and "numbers" come in. To understand trade-offs, eliminate unnecessary components, and identify the specific failure modes of each part, you must define the numbers.
The most common mistake in interviews (one I have made many times myself) is the "pattern matching" trap. You rush to give an answer instead of asking the interviewer questions, and as a result, you try to automatically apply the "patterns" learned from books. Let’s start prioritizing questions over immediate answers, and then design systems based on those findings. Let's strive to understand the specific failure modes, trade-offs, and numbers behind every component.
Examples of questions you should ask include:
- How many users will visit the system?
- What is the read-to-write ratio?
- How much traffic is expected?
- Which component of the system is likely to break first?
- (Note: You listed traffic twice in the source, I have kept the spirit of inquiry here).
- Etc.
Good Design
After asking your questions, pick any component and scrutinize its value. Database? What if write operations are fine, but reads start lagging? Cache? What if the cached requests are highly volatile and expire constantly? Load Balancer? What if the health checks pass, but the service internally is actually dead (zombie process)?
Walk through different scenarios. Think out loud; write and think on paper. Just think. This is exactly where you will see the books fail. You become experienced. You learn to think broader and deeper. You attempt to understand the specific failure modes, trade-offs, and numbers of each component. The goal of the interview isn't actually to produce the "correct" design; it is to demonstrate your ability to think through ambiguity, defend trade-offs with numbers, and adapt when constraints shift.
Redis for caching, Postgres for strong consistency, Kafka for event streaming, Rust for memory safety and speed—these are all strong choices. But they aren’t always the right answer.
Conclusion
I have made all the mistakes mentioned above, but making mistakes isn't the point learning from them is. The day you start understanding and calculating the numbers is the day you begin developing true intuition and experience in system design. Engineers at Big Tech companies build systems based exactly on these calculations, which is much closer to reality. The notion that "anything works in any situation" is a lie. You always give up something to get something else. Use questions to strip away unnecessary components, and study the failure modes and trade-offs of what remains.
Patterns may help in writing code or algorithms, but not in designing systems. Don’t memorize system design; learn to feel and understand it.
