System Design Reading Notes 2: A Framework for System Design Interviews

This is my reading notes for Chapter 2 & 3 in book “System Design Interview – An insider’s guide (Vol. 1)”.

These 2 chapters provide a structured framework that guides candidates through the complex and often daunting process of a system design interview. This framework is particularly useful because it breaks down the interview into manageable steps, ensuring that both the interviewer and the candidate can navigate the session effectively.

Step 1: Understand the Problem and Establish Design Scope

The first step in the framework is to fully understand the problem before diving into solutions. This involves asking clarifying questions that help define the scope of the design. It’s crucial to resist the temptation to immediately start designing a solution without a thorough understanding of the requirements.

Key Actions:

• Ask Questions: Begin by asking the interviewer about the specific features that need to be built, the expected scale of the system, and any constraints. This helps in setting the right direction for the design process.
• Clarify Requirements: Understand what is most important for the system. For instance, if you’re asked to design a news feed system, inquire whether the feed should be sorted chronologically or based on some other criteria.
• Write Down Assumptions: If the interviewer leaves some aspects of the design open to interpretation, clearly state your assumptions and write them down. This ensures that both you and the interviewer are on the same page.

Example: For a question like “Design a news feed system,” you might ask:

• “Is this for a mobile app, a web app, or both?”
• “Should the feed be sorted chronologically or by relevance?”
• “What is the anticipated user base?”

These questions help in understanding the exact requirements and constraints, allowing you to tailor your design appropriately.

Step 2: Propose High-Level Design and Get Buy-In

Once you have a clear understanding of the problem, the next step is to propose a high-level design. This involves creating an architecture that addresses the key requirements and is scalable to the anticipated user base. At this stage, it’s important to collaborate with the interviewer, treating them as a teammate.

Key Actions:

• Draw Diagrams: Use diagrams to represent the key components of your design. This could include clients (mobile/web), APIs, servers, data stores, and other essential components.
• Do Back-of-the-Envelope Calculations (More details in Appendix section): Perform quick calculations to ensure that your design can handle the expected load. For instance, if you’re designing a system for 10 million daily active users, estimate whether your architecture can support that scale.
• Collaborate with the Interviewer: Regularly check in with the interviewer, asking for feedback on your design. This not only ensures that you’re on the right track but also demonstrates your ability to work collaboratively.

Example: In the case of designing a news feed system, your high-level design might include:

• Feed Publishing Flow: A flowchart showing how a user’s post is stored in a database and how it is propagated to the feeds of the user’s friends.
• Feed Retrieval Flow: Another diagram detailing how the system retrieves posts from the database to build a user’s feed.

These diagrams help in visualizing the system, making it easier for the interviewer to follow your thought process.

Step 3: Design Deep Dive

After agreeing on the high-level design, the interview typically moves into a deep dive into specific components. This is where you demonstrate your technical expertise by discussing details such as data storage solutions, caching strategies, and algorithms.

Key Actions:

• Prioritize Components: Focus on the most critical components of the system first. For example, in a chat system, you might prioritize discussing how to ensure low latency.
• Discuss Alternatives: If time permits, discuss alternative approaches and their trade-offs. This shows that you’ve considered multiple solutions and chosen the most appropriate one.
• Manage Time: Be mindful of the interview duration. Ensure that you cover the most important aspects of the design without getting bogged down in unnecessary details.

Example: Continuing with the news feed system example, you might dive into:

• Feed Publishing Optimization: Discussing how to use a cache to reduce the load on the database when propagating posts.
• Scaling the Feed Retrieval: Exploring how to shard the database to handle a large number of users.

This step demonstrates your ability to think critically about the system and make informed decisions based on trade-offs.

Step 4: Wrap Up

The final step involves wrapping up the discussion by summarizing your design, discussing potential bottlenecks, and suggesting improvements. This step is crucial for leaving a strong final impression.

Key Actions:

• Summarize the Design: Recap the key components and flows of your design, ensuring that the interviewer has a clear understanding of your approach.
• Identify Bottlenecks: Discuss any potential bottlenecks in your design and propose solutions to address them. This could include scaling strategies, load balancing, or caching.
• Propose Future Enhancements: If time allows, suggest how the system could be further improved or scaled in the future.

Example: In the wrap-up for a news feed system, you might say:

• “To handle 10 million daily active users, we’ve designed the system to use database sharding and caching. However, as the user base grows, we might need to consider additional optimizations like further partitioning the database or using a distributed cache.”

This step helps in tying everything together and shows that you’ve thought about the system’s future needs.

Conclusion

The framework presented in Chapter 3 is designed to help both the candidate and the interviewer navigate the system design interview process smoothly. Back-of-the-envelope estimations help set realistic expectations, while a structured framework ensures thorough and adaptable designs. By breaking the interview down into these four steps—understanding the problem, proposing a high-level design, diving into specific components, and wrapping up the discussion—you can ensure a thorough and well-structured approach to any system design problem. This not only demonstrates your technical skills but also your ability to collaborate, communicate, and think critically, which are essential qualities for a successful software engineer.

Appendix – Back of the Envelope Estimation

Chapter 2 emphasizes the importance of back-of-the-envelope estimation, a technique crucial in system design interviews. This method involves making quick, rough calculations to assess the feasibility of a design based on basic arithmetic and commonly known performance metrics. The chapter introduces several key concepts essential for performing these estimations:

1. Power of Two: Understanding how data volume scales using powers of two is fundamental. For instance, knowing that 1 KB = 1024 bytes and 1 MB = 1024 KB is crucial when estimating storage or memory requirements.
2. Latency Numbers: The chapter provides a list of typical latency numbers for various operations, such as memory access, disk reads, and network transfers. For example, accessing memory is much faster than performing a disk seek, which influences decisions like whether to use in-memory data processing or disk-based storage.
3. Availability Numbers: Availability, often expressed as “nines” (e.g., 99.9% uptime), is crucial for designing systems that require high reliability. The chapter discusses how to estimate the downtime for different levels of availability and how this impacts system design.

Example: Estimating Twitter QPS and Storage Requirements

The chapter provides a practical example where the task is to estimate the query per second (QPS) and storage requirements for a platform like Twitter. Given assumptions such as 300 million monthly active users, where 50% use Twitter daily, the chapter walks through the following calculations:

This leads to an estimated total media storage of about 55 PB over five years. The example demonstrates the importance of making reasonable assumptions and using them to arrive at a quick estimate.