The System Design Interview (SDI) is the ultimate Rorschach test for software engineers. Handed a blank whiteboard and a vague prompt like "Design Twitter," candidates reveal exactly how they approach complex, ambiguous problems.
Having analyzed the defining literature on system design—from Alex Xu's System Design Interview to Martin Kleppmann's Designing Data-Intensive Applications—and studied the core curriculum of system design fundamentals (like those from Hayk Simonyan and AlgoMaster), a clear pattern emerges. The engineers who fail these interviews rarely fail because they don't know enough technologies. They fail because of how they approach the problem.
Let's use the Richard Feynman Technique—translating complex scenarios into simple, everyday analogies—to explore the four most common ways candidates sabotage their own System Design Interviews, and how to avoid them.
1. The Prescription Without Diagnosis (Jumping to Architecture)
Imagine walking into a doctor's office with a mild headache. Before you can even sit down or explain your symptoms, the doctor shoves a massive bottle of heavy-duty prescription painkillers into your hands and yells, "Take these twice a day!"
You'd run out of the room. Yet, this is exactly what happens in an SDI.
The Prescription Without Diagnosis: Prescribing a complex architecture before asking a single clarifying question about the requirements.
The interviewer says, "Design a URL shortener," and the candidate immediately replies: "Okay, I'll use a cluster of Node.js microservices, a Cassandra database for high write throughput, and Redis for caching!"
Why this fails:
You just prescribed medicine without examining the patient. System design prompts are intentionally vague. Are we building this for 10 users or 10 million? Do the links expire? Do we need analytics?
By jumping straight to solutions, you bypass gathering Functional Requirements (what the system must do—like short-link generation, custom aliases, and expiration) and Non-Functional Requirements (the constraints—like high availability, low latency, and read/write ratios).
Furthermore, you lock yourself into technologies before knowing your data structure. For instance:
- SQL (The Filing Cabinet): Structured, strict schemas, perfect for ACID transactions.
- NoSQL (The Storage Crates): Schema-less, easily horizontally scalable, great for high-volume writes.
- Graph Databases (The Social Network Map): Ideal for highly connected data (like friendships or recommendations).
Proposing Cassandra before you know if the data has complex relations is a major red flag.
The Fix:
Be the doctor. Spend the first 10-15 minutes gathering requirements. Understand if you need:
- REST (The Set Menu): Standard, predictable endpoints.
- GraphQL (The Custom Buffet): Client-specified queries to avoid over-fetching/under-fetching.
- gRPC (The Pneumatic Mail Tube): High-speed binary communication (Protobuf) for internal microservices.
Never draw a box until you understand the scope.
2. The Infinite Teacup (Ignoring Estimation & Network Physics)
Imagine trying to pour an entire roaring waterfall into a delicate, 4-ounce porcelain teacup. No matter how nice the teacup is, it's going to overflow instantly.
In the interview, this happens when candidates design a system without doing any back-of-the-envelope estimation or ignoring the physical limits of networking.
The Infinite Teacup: Designing a system without running back-of-the-envelope calculations, assuming infinite resources or vastly underestimating scale.
Candidates often design systems assuming that bandwidth is infinite, latency is zero, and a single server setup can handle anything.
Why this fails:
If you don't calculate the math, you don't know if your design actually works.
- Latency vs. Throughput vs. Bandwidth: Latency is the delay (how long a single letter takes to arrive), Throughput is the rate of processing (how many letters you process per second), and Bandwidth is the capacity of the pipe.
- SPOF (Single Point of Failure): Placing your entire system behind a single server, a single database, or a single DNS server without redundancy. If that single server goes down, the entire system crashes.
If your system ingests 10,000 requests per second (RPS), and each request is 1MB, that's 10GB per second. A standard gigabit network interface cards (NIC) will saturate instantly. Your database will melt.
The Fix:
Calculate the flow of the waterfall. Estimate:
- Daily Active Users (DAU) and Concurrent Users.
- Read/Write ratios to determine if the system is read-heavy (needs caching/CDNs) or write-heavy (needs message queues/sharding).
- Storage requirements for 5 years.
- Network bandwidth.
These numbers tell you whether a simple relational database on a single VM is sufficient, or if you must distribute the data using Replication (mirroring databases for read scaling) or Sharding/Partitioning (splitting data across different servers based on a partition key).
3. The Semi-Truck Pizza Delivery (Over-Engineering & Tool Worship)
You order a single medium pepperoni pizza. Twenty minutes later, an enormous, 18-wheeler, heavy-duty semi-truck with a roaring diesel engine pulls up to your driveway just to hand you that one small box.
The Semi-Truck Pizza Delivery: Using massively complex, enterprise-grade distributed systems to solve a problem that could be handled by a simple monolith.
This is the most common trap for eager candidates. They want to show off every buzzword they learned. So, to design a simple internal dashboard used by 50 employees, they propose a Kubernetes-orchestrated, event-driven microservices architecture using Apache Kafka, a CDN, Consistent Hashing, and an API Gateway.
Why this fails:
Every technology introduces complexity, operational overhead, and latency.
- Consistent Hashing: Great for dynamically scaling cache clusters without rebuilding the whole hash table, but useless for a static 2-node cache.
- Message Queues (like Kafka): Excellent for decoupling high-throughput asynchronous workloads, but adds eventual consistency and debugging complexity.
- CDN (Content Delivery Network): Ideal for caching static assets geographically close to the user, but completely unnecessary for dynamic, private dashboard data.
Interviewers view "resume-driven development" and unnecessary complexity as a massive red flag. It shows you don't understand the costs of the tools you recommend.
The Fix:
Start simple. Propose the simplest possible architecture that meets the requirements:
- A DNS server pointing to a Load Balancer.
- A Load Balancer distributing traffic to stateless Web Servers.
- A Relational Database with a Cache (like Redis) in front of it.
Only introduce complex tools (like message queues, microservices, or sharding) when the simple design hits a specific, mathematically proven bottleneck.
4. The Indestructible Sinking Bridge (Ignoring Trade-offs & Security)
An engineer is tasked with building a bridge. To ensure it absolutely never breaks under any circumstances, they build it out of the thickest, heaviest solid steel and concrete possible. It's truly indestructible! But it's so heavy that it instantly sinks into the mud at the bottom of the river.
The Indestructible Sinking Bridge: Designing for "perfect" consistency and availability without acknowledging the reality of architectural trade-offs.
In an interview, candidates often try to design a "perfect" system that has zero trade-offs. They claim they can have 100% consistency, 100% availability, instant responses globally, and absolute security without any performance cost.
Why this fails:
They forgot the fundamental laws of distributed systems:
- The CAP Theorem: In the presence of a network partition (P), you must choose between Consistency (C) or Availability (A). You cannot have both.
- Synchronous vs. Asynchronous: Synchronous communication (like REST/HTTP) waits for responses, keeping connections open. Asynchronous communication (like Message Queues) decouples systems but introduces lag.
- Security & Protection: Failing to include Rate Limiting (to prevent DDoS attacks and API abuse) or Authentication/Authorization (verifying identity and permissions). A system that is "perfectly consistent" but easily hackable or bring-downable by a script is useless.
The Fix:
Embrace the trade-offs. Every engineering decision is a compromise.
- If you choose Consistent Hashing, explain that it minimizes cache misses during scaling, but introduces complexity in node tracking.
- If you implement Rate Limiting, discuss token bucket vs. leaking bucket algorithms.
- If you choose asynchronous replication, explicitly state: "We choose Availability and Low Latency over Consistency. We accept that some users might see eventually consistent data for a few seconds."
- Implement security layers (like HTTPS, API Gateways, OAuth2/JWT for Auth, and Rate Limiters) and acknowledge their latency impact.
Conclusion
A System Design Interview isn't a trivia contest about who can name the most AWS services. It is a live, collaborative simulation of real-world software engineering.
The next time you walk into a whiteboard session:
- Don't prescribe without diagnosing: Gathering requirements is your diagnostic exam.
- Don't pour an ocean into a teacup: Run the estimations to size your pipes.
- Don't deliver a pizza in a semi-truck: Keep it simple until scale forces complexity.
- Don't build a sinking bridge: Acknowledge trade-offs, security, and the CAP theorem.
Master these principles, and you'll navigate the panic room with the confidence of a seasoned architect.
References & Further Reading
This guide synthesizes core methodologies and patterns from the defining literature on system design interviews:
- System Design Interview – An Insider's Guide (Volume 1 & 2) by Alex Xu and Sahn Lam.
- Designing Data-Intensive Applications by Martin Kleppmann.
- System Design Essentials (curriculum by Hayk Simonyan and AlgoMaster).
Follow Me
If you enjoyed this Feynman-style guide, feel free to follow me on:
Originally published at https://chemacabeza.dev/writing/how-not-to-tackle-a-system-design-interview.
Top comments (0)