A Senior Engineer's Guide to the System Design Interview

A System Design Framework for Senior Engineering Interviews

Part 3 is a ~40 minute read

Table of Contents

Part 1: How to approach a system design interview

Part 2: 15 fundamental system design concepts

Part 3: A 3-step framework to crush any system design interview

Part 4: Watch us design simple systems from scratch, and learn how to get unstuck

Part 3 Intro

You’ve made it to Part 3! So far, you’ve learned some high-level strategies in Part 1 and some fundamental concepts in Part 2. Now it’s time to get practical. Part 3 is the first time all of these theories start to fit together into something you can actually do. In other words, it’s time to learn a process to start designing systems.

About this 3-step framework

Fundamentals of this framework

1. We propose an opinionated method that can be applied to reason over most system design interviews. The less you have to think about the process, the more you can focus on the problems at hand.
2. Our method is broken down into 3 steps. Each of these steps can be seen as functions. They take inputs and have one output. As such, they can be practiced in isolation.
3. We’re teaching you a process. This means you’ll be ahead of most people who might be very knowledgeable in a few topics but lack a process. You’ll come across as a systematic problem solver who’s able to decompose a problem and come up with a reasonable architecture in 30 minutes. Again, you only have to understand 20% of the concepts to address 80% of problems you’ll encounter.

How to use this framework

In order to use this framework effectively, each step needs to be practiced separately. The three steps are:

1. Requirements
2. Data types, access patterns, and scale
3. Design

Limitations

This is a prescriptive method. As such, the approach might not fit 100% of the system design questions that you encounter. We designed this method to help mid-level / senior engineers get started with system design interviews by using a systematic approach and developing a framework to tackle these questions effectively. You should take this and adapt it so it works best for you.

Overview of the 3 steps

Step 1: Requirements

Step 2: Data Types, API and Scale

Step 3: Design

Step 1: Requirements

System design questions are open-ended and highly underspecified. Inexperienced candidates often dive right into design, without having the full picture of what needs to be built. This is a mistake.

The first step is to specify the requirements. It’s up to you to ask the right questions.

Rule of thumb

What makes these questions difficult or complicated is not the fact that they are inherently complicated. It's because the interviewer intentionally chooses to withhold information. Information that you can only get if you ask the right questions.

1.1 Functional Requirements

You should start with the functional requirements first—that is, the core product features and use cases that the system needs to support.

Identify the main business objects and their relations

Here are a few steps to guide your requirement gathering:

Example of Functional Requirement gathering

Example 1: Design TikTok

Let's say you are not familiar with TikTok. What do you do next? Probably ask your interviewer, right?
Even if you know the platform well, it’s wise to start by clarifying rather than assuming.

1. Identify the main objects and their relations

In this case there are two main objects: (1) Accounts and (2) Videos.

1.2 Non-Functional Requirements

Once functional requirements have been laid out, you should move onto non-functional requirements (NFRs). These are quality attributes that specify how the system should perform a certain function.

Remember: Non-Functional Requirements

Consider the three main non-functional requirements: performance, availability, and security.

1. Performance: Which access patterns, if any, require good performance?
2. Availability: What’s the cost of downtime for this system?
3. Security: Is there any workflow that requires special security considerations?

Step 2: Data Types, API and Scale

2.1 What data types does the system need to store?

Example: Design a code deployment system aimed for developers at a company. They should be able to tag a release, and our system will package it and deploy it to some servers.

Artifact: (product name, version, commit hash)

2.3 What volume of requests do we need to support?

Let's pause for a moment to reassess where we stand. We know how our API looks and which endpoints are going to be hit more frequently (read-heavy vs. write-heavy). This alone should be enough for us to start sketching out a design.

Remember: Data Types, Scale, and Access patterns

1. Data Types: Start by identifying the main business objects that you need to store.
2. API: How are these going to be accessed?
3. Scale: Is the system read-heavy or write-heavy?

Step 3: Design

The time has come. We’ve got all the information we need to start drawing boxes and calling this a “system.” Yay!

3.1 Data storage

Blob storage

Let’s get some of the more obvious components out of the way first.
Some popular blob stores are Amazon S3 and Azure Blob storage.

3.1.1 Relational vs. Non-Relational

Relational vs. Non-Relational, sometimes referred to as SQL vs. NoSQL, is one of the foundational decisions of database design.

Remember

There’s no right or wrong answer—it’s all about how to justify your picks.

Examples

1. Design a banking system.

This is a textbook example of strong consistency. Transactions in a banking system need ACID guarantees.

2. Design a system to help doctors diagnose potential illnesses given symptoms.

In this example, it might be wise to pick a non-relational database where we can store large volumes of unstructured data.

3. Design Amazon.

We’d want to have consistency for product transactions, while being flexible about the data in our product catalog.

Entities to store

Let’s see what this might look like through the lens of our Twitter example.

We identified two entities: (1) Accounts, and (2) Tweets. Therefore, we’ll start out nice and simple with two tables.

• Accounts: id, name, surname.
• Tweets: id, content, author_id, media_url.