A structured approach to ace system design interviews. Learn how to break down complex systems, identify requirements, and design scalable solutions.
Bikash Jaiswal
Get exclusive content, early access to new articles, and insights on software development, system design, and entrepreneurship delivered to your inbox.
The System Design Delivery Framework is a structured approach to ace system design interviews.
In an interview, you always want to clarify requirements first:
Break the requirements into two categories:
Oftentimes this is a back and forth with your interviewer.
The task is to identify top 3 features as Functional Requirements and focus on them. Functional requirements are your "Users/Clients should be able to..." statements.
Oftentimes this is a back and forth with your interviewer.
Example for Twitter:
Example for E-commerce:
Example for Cache:
Talks about the system's performance, scalability, and other non-functional requirements.
Example for Twitter:
The task is to identify top 3-5 non-functional requirements and focus on them. Put in the context of the system where it is being used. eg:The system should have low latency search, < 500ms
Identify the core entities in the system. Ask yourself following questions:
Think in terms of nouns (resources) — not actions. For example: For booking API -> movies, showtimes, bookings, users For Twitter: eg -> User, Tweet, Like, Follow
For E-commerce: eg:User, Product, Order, Cart, Payment
For Cache: eg:User, Product, Order, Cart, Payment
Also for real-time APIs, you can use WebSockets or Server-Sent Events (SSE). But for most cases, REST API is sufficient.
for Twitter end to end system design, you can use REST API
1GET /v1/tweets/{tweet_id} -> Tweet
2
3POST /v1/tweets
4body: {
5 "text": "Hello World"
6}
7POST /v1/follows
8body: {
9 "user_id": "123",
10 "followed_user_id": "456"
11}
12
13GET /v1/feed/{user_id} -> FeedResources should be plural nouns that represent things in your system use plural resource names (tweets, not tweet) The current user is derived from the authentication token in the request header, not from request bodies or path parameters.
By now you should have a good understanding of the system and its requirements, Core entities and API design Now start thinking about the high level architecture of the system.
Ask your recruiter what software you'll be using for your interview and practice with it ahead of time. You don't want to be fumbling with the software during your interview.
Now that you have a high-level design in place you're going to use the remaining 10 or so minutes of the interview to harden your design by: Ensuring it meets all of your non-functional requirements
Use this time to strengthen your design by:
Twitter Example: Talk about Scaling to 100M+ Users using below components
Finally, Make sure you give your interviewer room to ask questions and probe your design. Chances are they have specific signals they want to get from you, and you're going to miss it if you're too busy talking. Plus, you'll hurt your evaluation on communication and collaboration