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