There is a ritual in our industry known as the system design interview. We tend to dread it. We dread it not just because the stakes are high, but because it feels artificial. You stand before a whiteboard (or a shared Google Doc), and a stranger asks you to design Netflix or WhatsApp in forty-five minutes.
The common reaction is to treat this as a test of trivia. We memorize the difference between RabbitMQ and Kafka. We memorize the latency numbers of an L1 cache versus a network round-trip. The result is we treat the interview as a game of keywords, which is wrong.
The constraints of the interview—the shortage of time, the ambiguity of the prompt, the skeptical audience—are not bugs. They are the same constraints we face in the real world, merely compressed.
The ability to design a system in forty-five minutes isn't about memorization. It is about something far more valuable: the ability to impose structure.
The blank page
When you are asked to "Design a URL shortener," the difficulty is not the technology. We all know how to generate a hash. The difficulty is the blank page. The problem is infinite. Should you focus on the database schema? The API? The load balancer? The analytics pipeline?
Most engineers, myself included, have a tendency to dive into the part we find most interesting. If you love databases, you start designing the schema. If you love networking, you start drawing load balancers.
This is a mistake. It is like trying to build a house by starting with the choice of doorknobs. Let’s try with a top-down approach.
The contract
The first step is always the constraints, the requirements. In engineering, the constraints are functional and non-functional. Functionally: What must this thing do? Non-functionally: How much must it hurt?
If you don't ask about the scale—the Read/Write ratio, the expected latency, the consistency model—you aren't designing a system; you are guessing. A system that handles 100 requests per second is fundamentally different from one that handles 100,000. One is a Django app on a single server; the other is a distributed system with sharding and replication. If you don't establish the numbers upfront, you cannot choose the tool.
Nouns before verbs
There is a tendency in software to obsess over the "verbs"—the algorithms, the processing, the flow. We want to talk about how the data moves. Let’s try to define the core entities first.
This resonates with an old idea in computer science:
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." - Fred Brooks (1975)
When you define the data model—the User, the Video, the Comment—and how they relate to each other, the architecture often emerges naturally. If you know that a User has millions of Followers, you immediately know that a simple relational join will be too slow. You realize you need a fan-out strategy. The data dictates the design.
The interface
Before you draw a single server, define the contract between the system and the world. This is your API.
REST: reliable, understood, resource-oriented.
gRPC: fast, strict, internal.
GraphQL: let the client choose the exposure.
Don’t overthink this, but be precise. GET /feed implies a lot of backend complexity. Write it down. This is the contract you will be held to.
The breadth-first search
Once the constraints and entities are known, the temptation to “deep dive” returns.
But you must resist. You must first draw the “30,000-foot view.” You need a diagram that shows the entire path of a request, from the user’s phone to the database and back.
This is difficult because it feels superficial. You are drawing a box labeled “Service” and a cylinder labeled “Database,” and it feels like you are hand-waving. But this high-level design serves a purpose: it is an agreement on the boundaries.
The deep dive
Only after the structure is agreed upon do you zoom in. This is the "Deep Dive."
In an interview, you can't design everything. You have to pick the battles that matter.
If you are designing a chat app, the login service is boring. The interesting problem is WebSockets and message ordering.
If you are designing YouTube, the user profile is boring. The interesting problem is Blob storage and CDNs.
This is where the senior engineer distinguishes themselves from the junior. The junior engineer tries to make everything perfect. The senior engineer identifies the bottleneck—the single point where the system is most likely to break—and focuses all their energy there.
Conclusion
We often view structure as the enemy of creativity. We think that using a “framework” for a design discussion makes us sound robotic or corporate.
But I suspect the opposite is true. Structure is what permits creativity.
When you have a framework—when you know exactly what steps you need to take to break down a problem—you don’t have to waste mental energy worrying about whether you’ve missed something. You don’t have to panic about the time.
You are free to focus on the problem itself.
The system design interview is artificial, yes. But the chaos it simulates is real. And in a chaotic world, a little structure goes a long way.
Brilliant take on the nouns before verbs principle. I've seen so many architects jump straight into optimization patterns before they even understand what they're optimizing. That Fred Brooks quote is gold too,the data model realy does dictate the architecture more than people think.