Outline the Basic Design

We have discussed a few concepts of system design in the past few chapters. All of these concepts will get used in our design. For the system design questions, we need to focus on learning how to answer interview questions. Let us jump into designing the systems.

The most crucial concept for designing the system is to understand the requirement in detail.

Probe the interviewer

Systems are complex, and it is next to impossible to consider all the trade-offs in just a one-hour interview. On the other hand, the interviewer wants us to ask questions. It means they may intentionally give us vague problems. This shows them how well we navigate the ambiguity we may encounter on the job.

There is no one fixed solution for system design problems, and answers can vary from interviewer to interviewer. Due to all these reasons, we should not start solving the problem without understanding the prompt and assumptions in detail. Think of it like a brainstorming session with a set of open questions that we need to clear with the interviewer.

Here are a few steps we can use to approach the problem.

Understand the goal

It is critical to understand the goal of the system. Designs can vary based on the goal. Candidates can ask the following questions to understand the objective of the system:

• “What is the input and output of the system that we are going to design?”
• “What is the final goal, and who is going to use this system?”
• “Our design and its constraints can vary based on who is going to use the system”

Define the scope of the problem

In this section, we will define all the features of the system we will design. Always take a couple of minutes to think of all possible features before asking the interviewer.

Your questions may sound like this:

• “What type of platforms are we supporting for this system? Are we going to design for mobile as well?”
• “Do we need authentication for the users?”
• “What level of security is required by the system?”

Scale of the system

Our design will depend on the scale our system is going to handle. Also, the same set of feature requirements may sound different on a large scale.

It is critical to understand the scale that our system will handle. You can ask the following questions to learn more about the project scale:

• “How many users are going to be served by this system?”
• “What is the read and write ratio for the machine? Is it read-heavy or write-heavy?”
• “What is the average response time for the requests?”

The below list of questions might differ case-to-case, but these are commonly applicable.

• “How many queries per second can we expect from the user?”
• “What is the network throughput required?”
• “How much storage is required?”
• “Do we need memory to serve the clients faster?”

Trade-offs

It would be best if we made trade-offs to achieve the most suited system for the user requirements. Hence, it is worth discussing the possible trade-offs initially so we know the direction of the design.

There might be pros and cons of different on-shelf available solutions, but we need to confirm with the interviewer.

Our questions may sound like this:

• “What type of data are we going to store? Based on the data type, we need to confirm the type of database.”
• “Do we need high consistency or high availability of the system?”