On this page
Minute 0-5: Clarify Requirements
Functional Requirements
Non-Functional Requirements
Minute 5-10: The Back-of-the-Envelope Math
Calculate Traffic
Calculate Storage
Minute 10-20: High-Level Design (HLD)
1. The Client
2. The Load Balancer
3. The API Gateway
4. The Service Layer
5. The Database Layer
Minute 20-40: The Deep Dive
Scenario A: Streaming Audio/Video
Scenario B: Real-Time Chat
Scenario C: E-commerce Inventory
Minute 40-45: Bottlenecks & Trade-offs
Single Points of Failure (SPOF)
Consistency vs Availability
Conclusion
How to Design Any System: The 45-Minute Blueprint
Designing a massive software architecture from scratch is one of the most daunting challenges in the technology industry. The sheer number of variables, potential configurations, and technological choices can freeze even experienced engineers.
Success in these high-pressure scenarios does not come from memorizing every tool in existence. It comes from having a repeatable, structured approach that turns chaos into a roadmap.
When faced with an open-ended prompt to build a global system, the natural instinct is to rush. Many try to solve every problem at once, focusing on database schemas or specific algorithms before understanding the broader goals.
This lack of strategy leads to fragmented designs and unfinished solutions. However, senior engineers and architects understand that forty-five minutes is not enough time to build a perfect product. It is only enough time to demonstrate a clear, logical thought process.
By breaking the session into strict time blocks, complex ambiguity transforms into a manageable checklist.
Minute 0-5: Clarify Requirements
The biggest mistake one can make is assuming the problem is clear from the start.
The prompt provided in a system design interview is intentionally vague.
A statement like "Design a video streaming service" is not a specification; it is a trap. If one begins drawing servers immediately, the interview is likely already failed.
The first five minutes are for negotiation.
The goal is to define the boundaries of the system, often called the Minimum Viable Product (MVP). This is the smallest version of the product that still solves the core problem.
To define this, specific questions must be asked to categorize requirements into two buckets: Functional and Non-Functional.
Functional Requirements
These requirements define the specific behaviors of the system. They describe what the user can actually do. Clarifying these features prevents "scope creep," where the design becomes too bloated to finish.
For a generic messaging application, essential questions include:
- "Is this for one-on-one conversations, or does it support group chats?"
- "Do users need to see when the other person is typing?"
- "Can users send heavy media files, or is it text only?"
The answers dictate the architecture.
A group chat requires complex "fan-out" logic to distribute one message to many users, whereas a direct message is a simple point-to-point transfer. By asking these questions, one gains permission to ignore complex features and focus on the core task.
Non-Functional Requirements
These requirements define the quality and constraints of the system. This is where performance, reliability, and scale are discussed.
Key questions include:
- "Do we need to store the message history forever?"
- "How much latency (delay) is acceptable?"
- "Does the system need to be available 100% of the time, or is high consistency more important?"
These answers create a contract.
If the system must be fast, the design will prioritize memory caching.
If the system must never lose data, the design will prioritize durable disk storage. This list of requirements becomes the checklist for the rest of the session.
Minute 5-10: The Back-of-the-Envelope Math
Once the features are defined, the next step is to figure out the size of the system.
Many junior developers skip this step and select a standard database without knowing if it can handle the load. This is a red flag.
A solution that works for one thousand users will collapse under the weight of one million users.
You need to show an understanding of scale. This involves "back-of-the-envelope" math, using round numbers and powers of ten to get a rough idea of the necessary infrastructure.
Calculate Traffic
Start with the number of users. If the system has 50 million daily active users, and each user performs 10 actions a day, the system processes 500 million requests daily.
To make this number useful for engineering, it must be converted to Requests Per Second (RPS). There are roughly 100,000 seconds in a day (rounding up from 86,400 simplifies the mental math). 500 million requests divided by 100,000 seconds equals 5,000 requests per second.
This number tells a clear story.
A single modern server can handle a few thousand requests. Since the estimate is 5,000, a single server is risky.
A cluster of servers and a Load Balancer are definitely required to handle the traffic safely.
Calculate Storage
Next, translate the traffic into data accumulation.
If one message is roughly 100 bytes, and the system processes 500 million messages a day: 500 million multiplied by 100 bytes equals 50 gigabytes per day.
Over a retention period of 100 days, that is 5 terabytes of data.
This simple calculation justifies the technology choice.
A standard relational database can struggle with multi-terabyte datasets on a single machine. This result indicates that a "Wide-Column" database or a distributed storage solution is necessary.
By spending five minutes on math, the architectural decisions are no longer guesses; they are engineering conclusions.
Minute 10-20: High-Level Design (HLD)
Now that the requirements and scale are established, it is time to draw the blueprint. This phase focuses on the "Happy Path" (the flow of data when everything works perfectly). Do not worry about errors or edge cases yet.
For almost every large-scale web application, the structure looks very similar. Memorizing this standard layout provides a solid foundation to build upon.
1. The Client
The client is the starting point. This is the mobile app or web browser used by the human user. It sends requests over the internet to the system.
2. The Load Balancer
The first line of defense is the Load Balancer. Based on the math in the previous section, we know multiple servers are needed.
The Load Balancer sits between the client and those servers. It acts as a traffic controller, distributing incoming requests evenly across the server fleet. This ensures that no single server is overwhelmed while others sit idle.
3. The API Gateway
After the Load Balancer, the request often hits an API Gateway. This component acts as a router. It inspects the request and decides which internal service should handle it.
It also handles "cross-cutting concerns"; tasks that every request needs, such as checking if the user is logged in (authentication) or ensuring the user isn't sending too many requests (rate limiting).
4. The Service Layer
This is where the code lives. It contains the business logic. In a simple architecture, this might be one big application (a Monolith).
In a complex system, it is often split into "microservices."
For example, there might be a dedicated "User Service" for profiles and a "Chat Service" for processing messages.
5. The Database Layer
This is where data persists. Based on the storage math, this box is labeled with the specific type of database selected. It is often useful to draw a separate box for a "Cache" (like Redis) next to the database.
A cache stores frequently accessed data in memory, allowing the system to return data faster than reading it from the main database every time.
Draw these boxes clearly and connect them with arrows. Walk through the flow verbally, explaining how a request travels from the client to the database and back.
Minute 20-40: The Deep Dive
The high-level design shows breadth. This section shows depth.
The next twenty minutes are dedicated to the "Meat" of the interview. It is impossible to explain every single box in detail.
Instead, pick the one component that is unique to this specific problem and solve it thoroughly.
Different systems have different core challenges.
Here is how to approach the specific "hard problem" for three common scenarios.
Scenario A: Streaming Audio/Video
If designing a music app, the hard problem is not storing user data; it is delivering audio files to millions of people without buffering.
The focus here should be on CDNs (Content Delivery Networks).
A CDN is a network of servers located all over the world.
Instead of a user in London downloading a song from a server in New York, they download it from a local server in London.
The explanation should cover how popular songs are "cached" (stored) on these local servers to speed up delivery. It should also touch on how audio files are split into small chunks, allowing the user to start listening before the whole file is downloaded.
Scenario B: Real-Time Chat
If designing a chat app, the hard problem is immediate delivery. Standard web requests are slow because the client has to ask the server "Do I have new messages?" repeatedly. The focus here should be on WebSockets.
A WebSocket creates a persistent, open connection between the client and the server. This allows the server to push a message to the phone the instant it arrives, without waiting to be asked.
The explanation should cover how the server keeps track of which open connection belongs to which user, and how to handle millions of these open connections simultaneously.
Scenario C: E-commerce Inventory
If designing an online store, the hard problem is consistency. The system cannot sell the same item to two people at the exact same time.
The focus here should be on ACID Transactions.
ACID stands for Atomicity, Consistency, Isolation, and Durability. These are properties that guarantee database transactions are processed reliably.
The explanation should cover how the database "locks" the row for a specific item while a payment is processing. This ensures that if a second user tries to buy the item, they are forced to wait until the first transaction is finished.
Picking one of these challenges and explaining it in detail demonstrates technical expertise.
Minute 40-45: Bottlenecks & Trade-offs
The final five minutes are used to critique the design.
No system is perfect.
Every design decision comes with a trade-off. Identifying the flaws in the design before the interviewer does shows maturity and foresight.
Single Points of Failure (SPOF)
Look at the diagram and identify components that have no backup.
"This design works, but if the Load Balancer crashes, the entire system goes offline. We should add a secondary standby Load Balancer as a backup."
"If the primary database fails, we lose access to data. We should add a 'Read Replica' database that can take over if the main one fails."
Consistency vs Availability
This is a classic trade-off in distributed systems. One must decide if it is more important for the data to be perfect (Consistency) or for the system to always respond (Availability).
For a banking app, Consistency is required. It is better to show an error message than to show the wrong account balance.
For a social media app, Availability is usually preferred. It is okay if a "Like" count is off by one for a few seconds, as long as the feed loads quickly for the user.
Explicitly stating which side was chosen and why proves that the candidate is not just a coder, but an architect who understands business risk.
Conclusion
Designing a massive system in less than an hour seems impossible, but only if one tries to do it all at once.
By breaking the time down, the chaotic problem turns into a manageable checklist.
Summary of the Framework:
- 0-5 Minutes: Ask questions to define the MVP. Do not guess.
- 5-10 Minutes: Do the math to determine scale and storage needs.
- 10-20 Minutes: Draw the high-level components (Load Balancer, API, Database).
- 20-40 Minutes: Deep dive into the one specific technical challenge of the problem.
- 40-45 Minutes: Critique the work. Find the bottlenecks and explain trade-offs.
Next time you are standing in front of that whiteboard, take a deep breath. Check the clock. You have forty-five minutes. And start right away!
What our users say
ABHISHEK GUPTA
My offer from the top tech company would not have been possible without this course. Many thanks!!
Arijeet
Just completed the “Grokking the system design interview”. It's amazing and super informative. Have come across very few courses that are as good as this!
AHMET HANIF
Whoever put this together, you folks are life savers. Thank you :)
Designgurus on Substack
Deep dives, systems design teardowns, and interview tactics delivered daily.
Access to 50+ courses
New content added monthly
Certificate of completion
$33.25
/month
Billed Annually
Recommended Course
Grokking the System Design Interview
163,425+ students
4.7
Grokking the System Design Interview is a comprehensive course for system design interview. It provides a step-by-step guide to answering system design questions.
View Course
