System Design Interview Template | Ace the System Design Interview

Disclaimer: This article was written few years ago and may no longer be relevant as software engineering has changed a lot in the last few years. This is what may be more relevant now: Future of Software Engineering - Gaurav Chandak

System Design Series - Tutorials and Interview Template

System Design - Introduction | System Design Primer | Beginners

System Design - Scaling the application | System Design Primer

System Design - Scaling the database | System Design Primer

SQL vs NoSQL: Should we use SQL or NoSQL? | Databases

System Design Interview Template | Ace the System Design Interview

Note: This is the 5th part of the System Design series and assumes that you know the basic terminologies of System Design and know how to scale the application servers and the database.

A system design interview usually lasts for 45-60 minutes. It involves solving an abstract design problem. The problem would be something like 'Design WhatsApp'. You would not be provided with any other requirements at this stage.

Note: Consider that the interviewer is a product manager. They want to understand how you'll be creating the system. They will help you with the requirements. Do not assume any requirement.

Step 1: Gather Requirements [10-15 mins]

The first step of a system design interview is to gather the exact requirements for the given problem statement. When you are asked to design WhatsApp, your design is not expected to consider all the functionalities that WhatsApp provides.

Let's say you don't know what WhatsApp is, you should start by mentioning that you don't know about it. The interviewer would, let's say, respond with "it is a chat application".

Once you have a broad idea about the problem statement, ask for all the requirements.

Functional Requirements (FR) [5-7 mins]

Start by gathering the features (Functional Requirements) that the chat application should have. Think of common features that such an application might have. After every question, wait for the interviewer to answer and note it down. Provide your inputs if required.

Examples:

Do we need to support only 1:1 chat or group chats as well?
Do we need to support only text messages or media as well?
Do we need read receipts? [Discuss the specifics]
Do we need 'Online' and 'Last Seen' timestamps?
Do we need to support audio/video calls? If yes, do we need to support group calls as well?
Do we need to support message broadcasting?
Do we need to support status updates (images/videos/text)?
Should the chat messages be stored just on the device? How do we provide backup? Do we support multiple devices?
Do we need to support end-to-end encryption?
What profile information would each user have and which of them would be public? [This should be a discussion. Provide options that you can come up with]
Any other requirements that we would want to have?

The interviewer would mostly say yes to 4-5 features that you ask for. The first 4-5 features that you ask for would most likely be approved. Spend a minute thinking about and choosing/ordering the features that you are going to ask about.

Most good interviewers avoid bias about the features that they want to see before you start gathering the requirements. They want to understand your thought process and solutioning.

Non-Functional Requirements (NFR) [5-10 mins]

Once you have an idea about the functionalities (FR), you need to clarify the non-functional requirements from the interviewer. After every question, wait for the interviewer to answer and note it down. Provide your inputs if required. Some of these questions would be dependent on the approved functional requirements.

Examples:

How many users would be concurrently using the service on average and at peak times?
How many messages do we expect to be sent per day?
What would be the maximum number of characters in each text?
What is the expected average latency for users to get the messages after coming online?
What can be the maximum size of the group?
Would the media be downloaded locally or does it need to be loaded every time it is opened?
How big could the media files be?
What would be the Read/Write ratio for the different functionalities?
Indirectly ask if we should prefer consistency or availability for the various major features. Try to figure out if we need ACID transactions.
Examples:

In the case of chat, if we are storing messages permanently, the interviewer would most likely prefer consistency.
In the case of last-seen, the interviewer would most likely prefer availability.
In the case of status, the interviewer would most likely prefer availability.

These questions would help you identify the traffic, resource requirements, latency requirements, etc. It will also help you design your system based on consistency and availability requirements considering the trade-offs. Do a basic estimation at this stage.

Step 2: API Design [3-5 mins]

Based on the functional requirements, list down all the API endpoints that you need to expose from your system.

Make sure to double-check if you've supported all the approved requirements. Verify the same with the interviewer before moving to the next step.

Best Practices:

Step 3: High-Level Design and Discussion [15-20 mins]

Once the requirements are clear and you have the API design ready, it is time to sketch out the high-level design of your system.

Let's consider a sample high-level design of a given system. A basic overview of how the high-level design of a system might have these components:

Clients: Multiple mobile devices and laptops denoting the clients.
CDN: The clients would get static data from the CDN.
Load balancer: The clients would talk to a load balancer for dynamic data.
Application servers: There would be many application servers behind the load balancer.
Database: The application servers would talk to one or more SQL/NoSQL servers with some replication/sharding/partitioning involved.
Microservices: The application servers would talk to other internal servers if the system has a microservices architecture. Example: Auth Service.
Queue: The application servers would add some events/messages to a queue with certain workers listening to the queue for events.
Cache: The application servers might fetch data from the cache before hitting the database.

There could be other components as well and a few of these components might not be there in the design.

Let's sketch the above design to get a better idea.

Step 4: Metric Estimation [5 mins]

Estimate the different metrics of the different functionalities and your entire system. This would you help you decide the resources and number of machines required for each of the components.

The common metrics that you should estimate are:

Throughput
Latency
Memory
Storage

This can be approximately calculated based on the NFRs and the high-level system.

References: Latency numbers every programmer should know

Note: This step is generally not required for junior engineers (< 3 years of experience).

---

I hope that you got a decent idea on how to plan your system design interview.

I've created and used this template for my System Design Interviews at companies like Microsoft, Flipkart, Uber, Cleartax, Ola, etc. and I was able to clear the System Design round at all of these companies.

If you're a beginner in System Design then you may want to go through "System Design for Beginners" to get a decent idea about the different components and trade-offs involved in designing a scalable system.