How to approach System Design Interview

The system design interview is an open-ended conversation. As a candidate, we are expected to lead it along with a discussion with the interviewer.

System design is likely to be the final technical round question in every interview process. This question is probably discussed in top companies like Amazon, Microsoft, Google, Uber, and others and any other start-up. In either case, system design problems are fascinating and enjoyable to study. Let’s discuss some steps to solve system design problems.

Steps to approach a System Design Interview

Step 1: Requirements clarifications

It’s always a good idea to ask about the scope of the problem we’re trying to solve. Since design questions are often open-ended and don’t have a single correct answer, it’s important to clarify any ambiguities early in the interview. Candidates who take the time to describe the system’s end goals have a higher chance of succeeding in the interview.

Gather requirements and scope the problem. Ask questions to clarify use cases and constraints. Discuss assumptions.

• Who is going to use it?
• How are they going to use it?
• How many users are there?
• What does the system do?
• What are the inputs and outputs of the system?
• How much data do we expect to handle?
• How many requests per second do we expect?
• What is the expected read to write ratio?

Step 2: Back-of-the-envelope estimation

While the system we are going to design should be scalable, we need to start somewhere. This is why we need to define the scale of the system at first. We should think about the read-to-write ratio, the number of concurrent requests the system should expect, and various data limitations.

Once we define these parameters together with the interviewer, we can think of the best way to make that system work well and be scalable.

Step 3: Database Design

Before we design the hypothetical system, we need to define how we’re going to process data. Find out the main inputs and outputs, how they will be stored, and how the data will flow.

If we know what database would serve the purpose better, it’s going to be enough. Remember, we don’t need to go into detail too much at this stage.

Step 4: Create a high-level design

Outline a high-level design with all important components. Try to draw a diagram representing the system's core components. We should identify enough components that are needed to solve the actual problem from end-to-end.

Step 5: Design core components

Discuss in deep the major components; the interviewer’s input can often guide us to the system's parts that need more attention. We should present various approaches, benefits, and drawbacks and justify why we choose one.

Dive into details for each core component. For example, if we were asked to Design a Tiny-URL, discuss:

Generating and storing a hash of the full URL

• MD5 and Base62
• Hash collisions
• SQL or NoSQL
• Database schema

Translating a hashed URL to the full URL

• Database lookup
• API and object-oriented design

Step 6: Scale the design.

Identify and address bottlenecks, given the constraints. For example, do we need the following to address scalability issues?

• Load balancer
• Horizontal scaling
• Caching
• Database sharding

Step 7: Identifying and resolving bottlenecks

We should try to discuss as many bottlenecks as possible and different approaches to mitigate them.

1. Is there any single point of failure in our system? What are we doing to mitigate it?
2. Do we’ve enough replicas of the data so that we can still serve our users if we lose a few servers?
3. Similarly, do we’ve enough copies of different services running such that a few failures will not cause a total system shutdown?
4. How are we monitoring the performance of our service? Do we get alerts whenever critical components fail, or their performance degrades?