System Design Interview: A Step-By-Step Guide

[00:00] In this video, we talk about the System Design Interview Framework that we use in the books.

[00:13] We explain why you might want to consider using something similar when you interview. Now 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.

[00:27] Without any structure, it is easy to waste precious time on things that don't matter. An unstructured interview makes it difficult for our interviewer to follow. Our framework provides a time-tested structure.

[00:39] It is simple and powerful. It leads us to ask the right question and focus on the right things. Here are the four steps of our framework. Step 1. Understand the problem and establish design scope.

[00:52] Step 2. Propose high-level design and get buy-in. Step 3, design deep dive. And Step 4 is wrap-up. This framework works well for a typical 45 to 60 minutes long system design interview session.

[01:08] Usually the first 5 minutes is an introduction and the last 5 is Q&A. The need of the interview is only about 35 to 45 minutes. We suggest allocating about 5 minutes to Step 1, 20 minutes to Step 2, 15 minutes to Step 3, and 5 minutes to Step 4.

[01:27] Now keep in mind this is just a rough guideline. Feel free to address as needed. Let's take a closer look at each of the four steps. Step 1. Understand the problem and establish design scope.

[01:40] 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.

[01:52] 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.

[02:04] 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 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

[02:36] 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's also important to ask a series of questions to clarify the non-functional requirements.

[02:52] For system design interviews, we suggest focusing on scale and performance. These non-functional requirements are what make our designs unique and challenging. For example, designing a Twitter clone to support a few hundred users is easy, while

[03:08] designing it for hundreds of millions of users, with some popular accounts having millions of followers, is interesting and challenging. The more senior the world is, the more important it is for us to demonstrate our ability to

[03:22] 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.

[03:34] Keep in mind that system and the potential challenges. 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 the magnitude right.

[03:47] This step should take about five 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.

[03:59] For step two 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 will suggest a top-down approach and start with the APIs.

[04:12] 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. Unlike to specify otherwise, we should follow the RESTful Convention.

[04:27] 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.

[04:44] An additional consideration on API some designs may call for two communication between client and server In this scenario WebSocket is a common solution here Be mindful that a socket service or WebSocket is usually stable It is quite challenging to operate a scale

[05:05] If 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.

[05:20] The diagram is a 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.

[05:36] Behind that are the services that will 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.

[05:50] It is usually not necessary to specify the exact database technology to use at this stage. This should be deferred to the deep dry section if necessary, and only after we have designed the data schema.

[06:03] For example, for a map service like Google Maps, the client often needs to send frequent GPS updates to the server, server. We include in the design a location data store that a location update service would like to.

[06:16] Repeat the steps above and complete the high level design diagram for all the major features. Here is a pro tip. While developing a high level design, maintain a list of discussion points for

[06:28] later. Resist the temptations 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.

[06:43] 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. It is simple. Also discuss the databases to choose and maybe discuss the indexing options.

[06:59] 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.

[07:15] 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 We should work with the interviewer

[07:33] 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

[07:48] sits-off approach. Here is where the ability to read the room is useful. Sometimes the interviewers body language will give away clues that they are dissatisfied with certain aspects of the design. It is important to pick up these

[08:01] clues and make sure the issues are addressed. One way we can approach it is by asking questions. We can list out the reasons for choosing a particular solution and ask if they have any questions or concerns. Once we pick out a

[08:15] a problem or two to dive deeper into, we can come up with multiple solutions and discuss trade-offs for each option. We could use the following mini-guidelines when framing the discussions. First, we should clearly articulate a problem. For example, for designing Google

[08:32] Maps, the wide QPS at 1 million per second to the location database is too high for a single database to handle. Next, we come up with at least two solutions. Continuing with

[08:45] example above, we could propose to reduce the location update frequency per user or choose a NoSQL database that could handle the right rate. Third, we discuss the trade-offs of the solutions. Remember to use numbers to back up our design.

[09:00] Finally, we pick a solution and discuss it with the interviewer. I'll repeat this for other problems. In a typical interview, we should only have time to dive deeper into the top two or three issues. Lastly, we have reached the last step, wrap-up. We suggest spending

[09:18] a few minutes summarizing the design. Here we should focus on the parts that are unique to the particular situation. Keep it short and sweet. Leave enough room at the end of the interview to ask the interviewer questions about the company. That's it on the system design interview

[09:35] 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.bitebygo.com.