Requirements (5 minutes)
Goal is to gather requirements and clear understanding of the system that you are being asked how to design. To make it easy, break down requirements into two sections
Functional Requirements
In this part, you need to know what your users or clients should be able to do. It will be core features of your system and should be the first thing you discuss with the interviewer. Ask questions like “Does the system need to do X”, “What would happen if Y” to get a prioritised list of core features.
Example
Imagine you design Twitter and you might come up with following requirements:
- Users should be able to post tweets
- Users should be able to follow other users
- Users should be able to see tweets from users they follow
Cache meanwhile might have req like:
- Clients should be able to insert items
- Clients should be able to set expirations
- Clients should be able to read items
Keep your requirements targeted
The goal is to develop system that meets requirements you’ve identified. Many systems have loads of features, but you need to choose and prioritise the top 3. The bigger the list, the more it will hurt you as companies evaluate if you can focus on what matters.
Non-functional requirements
There are the requirements that are related to a system.
Example
If you design a Twitter feed, it might be
- System should be highly available, prioritising availability over consistency
- System should be able to scale up to 100M DAUs
- Should have low latency, rendering feeds in under 200ms
NOTE
Non-functional requirements should be quantified if it is possible. Avoid having “should have low latency” and instead, have “system should have latency below <500ms”
When gathering non-functional requirements, focus on these
- Cap Theorem
- Environment Constraints: Where the system will run. Low battery devices, limited bandwidth, limited memory etc
- Scalability
- Latency
- Consistency
- Security - How secure the system should be
- Fault Tolerance - Whether system needs to handle failures (Failovers, recovery mechanisms, redundancy)
- Compliance: Any legal regulatory requirements that system needs to handle (Data protection laws, industry standards etc.)
Core Entities (2 minutes)
Identify core entities in your system as it will help you to define terms, understand the data central to your design and give you foundation to build on. In a system design, you can just do bullets and explain this is your first draft.
The reason is it better to just jot them down like this is because you don’t know what you don’t know at this point. You will discover new entities and relationships as you go.
Example
For our Twitter example, our core entities are rather simple:
- User
- Tweet
- Follow
API or System Interface (5 minutes)
Before high level design, define the contract between system and users. During full product style interviews, it maps to functional requirements you’ve already defined. It will help you to guide high level decision and ensure that you are meeting requirements you’ve identified.
For this, you can use one of the following:
- REST - This is the one you will most likely use 90% of time
- GraphQL - Choose this when you only need clients to fetch require ddata
- gRPC - Only when you need raw speed and your system does not communicate with your browsers.
Example
POST /v1/tweet
body: {
"text": string
}
GET /v1/tweet/:tweetId -> Tweet
POST /v1/follow/:userId
GET /v1/feed -> Tweet[]
// There's no `id` in a URL as this can be grabbed from a token, which is much safer. user IDs should never be added in a request body or URL for safety reason. It essentially is a risky thing to do.
Data Flow (5 minutes and Optional)
You can describe a high level sequence of actions or processes that the system will perform to produce the desired outcome. If your system does not have long sequence of actions, it’s optional.
Example
It may look like this for a web crawler
- Fetch seed URLs
- Parse HTML
- Extract URLs
- Store data
- Repeat
High Level Design (10-15 minutes)
During this section, you draw boxes and arrows to represent the different components of your system and how they interact. It will be servers, databases, caches etc. Usually done on a whiteboard or excalidraw.
Don’t overthink this, just focus on architecture that satisfied the API you’ve designed and satisfies the requirements. You can go one-by-one through API endpoints and build your design sequentially to satisfy each one.
Be explicit about the data flow through the system and what state changes with each request, starting from request and ending with response. When request reaches your persistence layer, document columns/fields for each entry. It can be done next to DB and don’t worry about types. Interviewer will infer it.
Open: Pasted image 20250405105122.png
Deep Dives (10 minutes)
Once you have a high level design, next you can deep dive and harden your design by ensuring that it meets all your non-functioanl requirements, addressing edge cases and identifying and addressing issues and bottlenecks, and improving design based on probes from the interviewer.
Whether you will have to go very deep or not depends on seniority. The more senior you are, the deeper you will have to go
Example
To statisfy >100M DAUs, we could lead a discussion oriented around horizontal scaling, introduction of caches and database sharding and updateing our design as we go. In case of quick reads, it would be a discussion about use of caches and fanout reads or writes