In this video, we talk about the system design interview framework that we used in our books. We explain why you might want to consider using something similar when you interview. Let’s first talk about why we might want to follow a framework. Interviews are stressful. There is very little time to show off what we are capable of. Without any structure, it is easy to waste precious time on things that don’t matter. An unstructured interview makes it difficult for the interviewer to follow. Our framework provides a time-tested structure. It is simple and powerful. It leads us to ask the right questions and focus on the right things. Here are the 4 steps in our framework. Step 1 - Understand the problem and establish design scope. Step 2 - Propose high-level design and get buy-in Step 3 - Design deep dive Step 4 - Wrap up This framework works well for a typical 45-60 minute long system design interview session. Usually, the first 5 mins is an introduction, and the last 5 is Q&A. The meat of the interview is only about 35-45 mins. We suggest allocating about 5 minutes to step 1, 20 mins to step 2, 15 mins to step 3, and 5 mins to step 4. Keep in mind this is just a rough guideline. Feel free to adjust as needed. Let’s take a closer look at each of the four steps. Step 1 - Understand the problem and establish design scope. System design questions are usually open-ended. Sometimes they are presented in a way that is deliberately vague. This tests our ability to organize our thoughts and focus on what is important. It is our job to ask as many questions as necessary to understand the problem fully. It is a red flag to jump right into a solution without first understanding what we are building. What questions should we ask? Our goal is to clarify the requirements. We want to understand why we are building the system, who the users are, and what features we need to build. For example, if we are asked to design a chat app, it is important to recognize that there are many different types of chat apps in the marketplace. There are one-on-one and small-group chat apps like WhatsApp, office chat apps like Slack, or group chat apps like Discord. They have different design challenges and constraints. The goal is to understand the features we are building in priority order. We should focus on the top few features to build. Make sure the interviewer agrees to the feature list. It is also important to ask a series of questions to clarify the non-functional requirements. For system design interviews, we suggest focusing on scale and performance. These non-functional requirements are what make our design unique and challenging. For example, designing a Twitter clone to support a few hundred users is easy, while designing it for hundreds of millions of users with some popular accounts having millions of followers is interesting and challenging. The more senior the role is, the more important it is for us to demonstrate our ability to handle the non-functional requirements. To help us get a sense of the scale of the system and the potential challenges and bottlenecks, we might do some rough back-of-the-envelope calculations here. Keep in mind that we have yet to design anything, so the math we do here is a rough estimate. The goal is to get a general sense of the scale. We want to get the order of magnitude right. This step should take about 5 minutes. At the end, we should have a short list of features to design for, along with a few important non-functional requirements to satisfy. For step 2 of our framework, we aim to develop a high-level design and reach an agreement with the interviewer on the design. For most designs, we would suggest a top-down approach and start with the APIs. The APIs establish a contract between the end users and the backend systems. It should be clear after gathering the requirements what APIs we would need. Unless it is specified otherwise, we should follow the RESTful convention. Define each API’s input parameters and output responses carefully. Take the time to carefully review the APIs. Verify that they satisfy the functional requirements. Equally important to remember. Do not introduce APIs that have nothing to do with the functional requirements. An additional consideration on API. Some designs might call for two-way communication between client and server. In this scenario, Websocket is a common solution here. Be mindful that a socket service like websocket is stateful. It is quite challenging to operate at scale. If the scale is high, be prepared to discuss how we would manage a WebSocket deployment in the deep dive section. Once we have established the APIs between the client and the server, the next step is to lay out the high-level design diagram. The diagram is the blueprint of the overall design that we can refer back to. We should use it to verify that the design satisfies all the feature requirements end-to-end. For many designs, it starts with a load balancer or an API gateway. Behind that are the services that would satisfy the feature requirements we established earlier with the interviewer. Many services require some form of persistence. This is where we would round out the design by introducing the data storage layer. It is usually not necessary to specify the exact database technology to use at this stage. This should be deferred to the deep dive section if necessary, and only after we have designed the data schema. For example, for a map service like Google Maps, the client often needs to send frequent GPS updates to the server. We would include in our design a location data store that a location update service would write to. Repeat the steps above and complete the high-level design diagram for all the major features. Here is a pro tip. While developing the high-level design, maintain a list of discussion points for later. Resist the temptation to dig into too much detail too early. Do not dig ourselves into a hole before we have a full picture of the design. The last step of the high-level design is to hash out the data model and schema. Here we should discuss the data access patterns and the read/write ratio. At scale, data modeling could significantly impact the performance of the design. If it is simple, also discuss the databases to choose, and maybe discuss the indexing options. Here we should make some judgment calls. If the data modeling is the key part of the design to satisfy the non-functional requirements, we might want to defer the discussion to the deep dive section. When we are done with the high-level design, take a step back and review the design. Make sure each feature is complete end-to-end. Here we reach the third step of the framework - design deep dive. The goal of this section is to demonstrate that we could identify areas that could potentially be problematic and come up with solutions and discuss trade-offs. We should work with the interviewer closely to decide what to discuss in depth. Deep dive is where non-functional requirements make the problem interesting. The higher the level, the more important this section is. The section is really open-ended. There is no one-size-fits-all approach. Here is where the ability to “read-the-room” is useful. Sometimes the interviewer’s body language would give away clues that they are dissatisfied with certain aspects of the design. It is important to pick up these clues and make sure the issues are addressed. One way we could approach it is by asking questions. We could list out the reasons for choosing a particular solution and ask if they have any questions or concerns. Once we pick out a problem or two to dive deeper into, we should come up with multiple solutions and discuss the trade-offs for each option. We could use the following mini guidelines when framing the discussion. First, we should clearly articulate the problem. For example, for designing Google Maps, the write QPS at 1 M/sec to the location database is too high for a single database to handle. Next, we come up with at least two solutions. Continuing with the example above, we could propose to reduce the location update frequency per user, or choose a NoSQL database that could handle the write rate. Third, we discuss the trade-offs of the solutions. Remember to use numbers to back up our design. Finally, we pick a solution and discuss it with the interviewer. Repeat this for other problems. In a typical interview, we should only have time to dive deeper into the top 2 or 3 issues. Lastly, we have reached the last step - wrap-up. We suggest spending a few minutes summarizing the design. Here we should focus on the parts that are unique to the particular situation. Keep this short and sweet. Leave enough time at the end of the interview to ask the interviewer questions about the company. That’s it on the system design interview framework. We hope you find it useful. If you like our videos, you may like our weekly system design newsletter as well. It covers topics and trends in large-scale system designs. Trusted by 200,000 readers. Subscribe at: blog.bytebytego.com