Chapter 4 A Framework For System Design Interviews

You have just landed a coveted on-site interview at your dream company. The hiring coordinator sends you a schedule for that day. Scanning down the list, you feel pretty good about it until your eyes land on this interview session - System Design Interview.

System design interviews are often intimidating. It could be as vague as “designing a well-known product X?”. The questions are ambiguous and seem unreasonably broad. Your weariness is understandable. After all, how could anyone design a popular product in an hour that has taken hundreds if not thousands of engineers to build?

The good news is that no one expects you to. Real-world system design is extremely complicated. For example, Google search is deceptively simple; however, the amount of technology that underpins that simplicity is truly astonishing. If no one expects you to design a real-world system in an hour, what is the benefit of a system design interview?

The system design interview simulates real-life problem solving where two co-workers collaborate on an ambiguous problem and come up with a solution that meets their goals. The problem is open-ended, and there is no perfect answer. The final design is less important compared to the work you put in the design process. This allows you to demonstrate your design skill, defend your design choices, and respond to feedback in a constructive manner.

Let us flip the table and consider what goes through the interviewer’s head as she walks into the conference room to meet you. The primary goal of the interviewer is to accurately assess your abilities. The last thing she wants is to give an inconclusive evaluation because the session has gone poorly and there are not enough signals. What is an interviewer looking for in a system design interview?

Many think that system design interview is all about a person's technical design skills. It is much more than that. An effective system design interview gives strong signals about a person's ability to collaborate, to work under pressure, and to resolve ambiguity constructively. The ability to ask good questions is also an essential skill, and many interviewers specifically look for this skill.

A good interviewer also looks for red flags. Over-engineering is a real disease of many engineers as they delight in design purity and ignore tradeoffs. They are often unaware of the compounding costs of over-engineered systems, and many companies pay a high price for that ignorance. You certainly do not want to demonstrate this tendency in a system design interview. Other red flags include narrow mindedness, stubbornness, etc.

In this chapter, we will go over some useful tips and introduce a simple and effective framework to solve system design interview problems.

您刚刚拿到了梦寐以求的公司现场面试机会。招聘协调员发送了当天的日程安排。当您浏览列表时感觉良好，但视线落在了其中一个面试环节上：系统设计面试。

系统设计面试通常令人望而生畏。它可能会模糊到像“设计一个著名的产品X”这样的问题。这类问题模棱两可，似乎范围广泛得不合理。您的顾虑是可以理解的，毕竟，如何能在一小时内设计一个产品，而这个产品可能耗费了数百甚至数千名工程师的心血？

好消息是，没人指望您真的这么做。现实中的系统设计极为复杂。例如，谷歌搜索表面上看起来很简单，但支撑这种简单性的技术量是惊人的。既然没人指望您在一小时内设计出一个现实中的系统，那么系统设计面试的意义何在？

系统设计面试模拟的是实际问题解决过程，场景为两位同事一起合作解决一个模糊的问题，并制定一个能达到目标的解决方案。这个问题是开放性的，没有完美的答案。最终设计的重要性不及您在设计过程中所投入的工作。这使您有机会展示自己的设计技能，捍卫设计选择，并以建设性的态度回应反馈。

让我们换个角度来考虑，作为面试官，她在走进会议室见您时心里在想什么。面试官的主要目标是准确评估您的能力。她最不希望的就是因为面试过程不佳、信号不足而无法给出明确的评估。在系统设计面试中，面试官在寻找什么呢？

许多人认为系统设计面试仅仅是关于一个人的技术设计能力。其实远不止如此。一场有效的系统设计面试能够强烈传递一个人协作能力、在压力下工作的能力以及以建设性方式解决模糊问题的能力。提出好问题的能力也是一项重要技能，许多面试官会特别关注这一点。

一位优秀的面试官也会留意一些负面信号。过度设计是许多工程师的一个真实问题，因为他们沉迷于设计的纯粹性而忽视权衡。这些人往往没有意识到过度设计的系统所带来的累积成本，而许多公司为此付出了高昂代价。在系统设计面试中，您当然不想表现出这种倾向。其他负面信号还包括思维狭隘、固执己见等。

在本章中，我们将介绍一些有用的技巧，并提出一个简单且有效的框架来解决系统设计面试中的问题。

A 4-step process for effective system design interview

Every system design interview is different. A great system design interview is open-ended and there is no one-size-fits-all solution. However, there are steps and common ground to cover in every system design interview.

每场系统设计面试都是不同的。一场优秀的系统设计面试是开放性的，没有一种放之四海而皆准的解决方案。然而，在每场系统设计面试中都有一些通用步骤和共同点需要涵盖。

Step 1 - Understand the problem and establish design scope

"Why did the tiger roar?"

A hand shot up in the back of the class.

"Yes, Jimmy?", the teacher responded.

"Because he was HUNGRY".

"Very good Jimmy."

Throughout his childhood, Jimmy has always been the first to answer questions in the class. Whenever the teacher asks a question, there is always a kid in the classroom who loves to take a crack at the question, no matter if he knows the answer or not. That is Jimmy.

Jimmy is an ace student. He takes pride in knowing all the answers fast. In exams, he is usually the first person to finish the questions. He is a teacher's top choice for any academic competition.

DON'T be like Jimmy.

In a system design interview, giving out an answer quickly without thinking gives you no bonus points. Answering without a thorough understanding of the requirements is a huge red flag as the interview is not a trivia contest. There is no right answer.

So, do not jump right in to give a solution. Slow down. Think deeply and ask questions to clarify requirements and assumptions. This is extremely important.

As an engineer, we like to solve hard problems and jump into the final design; however, this approach is likely to lead you to design the wrong system. One of the most important skills as an engineer is to ask the right questions, make the proper assumptions, and gather all the information needed to build a system. So, do not be afraid to ask questions.

When you ask a question, the interviewer either answers your question directly or asks you to make your assumptions. If the latter happens, write down your assumptions on the whiteboard or paper. You might need them later.

What kind of questions to ask? Ask questions to understand the exact requirements. Here is a list of questions to help you get started:

• What specific features are we going to build?
• How many users does the product have?
• How fast does the company anticipate to scale up? What are the anticipated scales in 3 months, 6 months, and a year?
• What is the company’s technology stack? What existing services you might leverage to simplify the design?

Example

If you are asked to design a news feed system, you want to ask questions that help you clarify the requirements. The conversation between you and the interviewer might look like this:

Candidate: Is this a mobile app? Or a web app? Or both? Interviewer: Both.

Candidate: What are the most important features for the product? Interviewer: Ability to make a post and see friends’ news feed.

Candidate: Is the news feed sorted in reverse chronological order or a particular order? The particular order means each post is given a different weight. For instance, posts from your close friends are more important than posts from a group. Interviewer: To keep things simple, let us assume the feed is sorted by reverse chronological order.

Candidate: How many friends can a user have? Interviewer: 5000

Candidate: What is the traffic volume? Interviewer: 10 million daily active users (DAU)

Candidate: Can feed contain images, videos, or just text? Interviewer: It can contain media files, including both images and videos.

Above are some sample questions that you can ask your interviewer. It is important to understand the requirements and clarify ambiguities

步骤 1 - 理解问题并确定设计范围

“为什么老虎会吼叫？”

教室后面有只手举了起来。

“是的，Jimmy？”老师回应道。

“因为它饿了。”

“非常好，Jimmy。”

在整个童年时期，Jimmy总是第一个回答问题的孩子。每当老师提问，总有一个喜欢尝试回答问题的孩子，无论他是否真正知道答案，而这个人就是Jimmy。

Jimmy是个优等生，他以快速知道所有答案为荣。在考试中，他通常是第一个完成答题的人，是老师在任何学术比赛中的首选。

不要像Jimmy那样。

在系统设计面试中，快速给出答案并不会为你加分。没有充分理解需求就作答是一个严重的失误，因为这并不是一场知识竞赛。这里没有所谓的“正确答案”。

所以，不要急于给出解决方案。放慢脚步，深入思考并通过提问来澄清需求和假设。这一点极其重要。

作为工程师，我们喜欢解决难题并直接进入设计阶段；然而，这种方法往往会导致设计出错误的系统。作为一名工程师，最重要的技能之一就是提出正确的问题，做出适当的假设，并收集构建系统所需的所有信息。因此，不要害怕提问。

当你提出问题时，面试官会直接回答或让你自行做出假设。如果是后者，请将你的假设写在白板或纸上，可能稍后会用到。

要问哪些问题？ 问问题以了解确切的需求。以下是一些可以帮助你入手的问题：

• 我们要构建的具体功能是什么？
• 产品的用户量有多大？
• 公司预计的增长速度有多快？在3个月、6个月和1年后的预期规模是多少？
• 公司使用的技术栈是什么？是否有现有的服务可以利用以简化设计？

示例

如果被要求设计一个新闻推送系统，你会想问一些有助于澄清需求的问题。你和面试官之间的对话可能如下所示：

候选人：这是一个移动应用吗？还是网页应用？或是两者都有？

面试官：都有。

候选人：这个产品的最重要功能是什么？

面试官：可以发帖并查看朋友的新闻推送。

候选人：新闻推送是按逆时间顺序排列还是特定顺序？特定顺序指的是每个帖子有不同的权重。例如，来自好友的帖子比群组中的帖子更重要。

面试官：为了简单起见，我们假设按逆时间顺序排列。

候选人：用户可以拥有多少好友？

面试官：5000人。

候选人：流量有多大？

面试官：1000万日活跃用户（DAU）。

候选人：推送内容可以包含图片、视频，还是仅限文本？

面试官：可以包含媒体文件，包括图片和视频。

以上是一些你可以向面试官提出的示例问题。理解需求并澄清模糊之处非常重要

Step 2 - Propose high-level design and get buy-in

In this step, we aim to develop a high-level design and reach an agreement with the interviewer on the design. It is a great idea to collaborate with the interviewer during the process.

• Come up with an initial blueprint for the design. Ask for feedback. Treat your interviewer as a teammate and work together. Many good interviewers love to talk and get involved.
• Draw box diagrams with key components on the whiteboard or paper. This might include clients (mobile/web), APIs, web servers, data stores, cache, CDN, message queue, etc.
• Do back-of-the-envelope calculations to evaluate if your blueprint fits the scale constraints. Think out loud. Communicate with your interviewer if back-of-the-envelope is necessary before diving into it.

If possible, go through a few concrete use cases. This will help you frame the high-level design. It is also likely that the use cases would help you discover edge cases you have not yet considered.

Should we include API endpoints and database schema here? This depends on the problem. For large design problems like “Design Google search engine”, this is a bit of too low level. For a problem like designing the backend for a multi-player poker game, this is a fair game. Communicate with your interviewer.

Example

Let us use “Design a news feed system” to demonstrate how to approach the high-level design. Here you are not required to understand how the system actually works. All the details will be explained in the "Design A News Feed System" chapter.

At the high level, the design is divided into two flows: feed publishing and news feed building.

• Feed publishing: when a user publishes a post, corresponding data is written into cache/database, and the post will be populated into friends’ news feed.
• Newsfeed building: the news feed is built by aggregating friends’ posts in a reverse chronological order.

Figure 1 and Figure 2 present high-level designs for feed publishing and news feed building flows, respectively.

在这一步中，我们的目标是制定一个高层次设计，并与面试官达成设计共识。与面试官协作是一个非常好的策略。

• 先提出一个初步设计方案并请求反馈。将面试官当作队友，共同探讨设计过程。许多优秀的面试官喜欢讨论并参与其中。
• 在白板或纸上绘制关键组件的框图。这可能包括客户端（移动端/网页端）、API、Web服务器、数据存储、缓存、CDN、消息队列等。
• 进行粗略计算（back-of-the-envelope calculations）以评估您的设计是否符合规模限制。思考时请大声说出您的思路。在深入计算前，先与面试官沟通是否有必要进行粗略计算。

如果可能，列举一些具体的用例。这将帮助您框定高层设计，并且有助于发现尚未考虑的边界情况。

是否应在此阶段包含API端点和数据库模式？这取决于问题的复杂性。对于“设计谷歌搜索引擎”这样的大规模设计问题，这样做未免过于详细。而对于设计多人在线扑克游戏的后端，这样的细节则是合理的。与面试官沟通以确定合适的层次。

让我们以“设计一个新闻推送系统”来演示如何进行高层次设计。在这里，您不需要理解系统的实际工作原理，所有细节将在“设计新闻推送系统”一章中解释。

在高层次上，设计分为两个流程：推送发布和新闻推送构建。

• 推送发布：当用户发布帖子时，相应的数据被写入缓存/数据库，并将该帖子推送到好友的新闻推送中。
• 新闻推送构建：通过聚合好友的帖子按逆时间顺序构建新闻推送。

图1和图2分别展示了推送发布和新闻推送构建流程的高层设计。

Step 3 - Design deep dive

At this step, you and your interviewer should have already achieved the following objectives:

• Agreed on the overall goals and feature scope
• Sketched out a high-level blueprint for the overall design
• Obtained feedback from your interviewer on the high-level design
• Had some initial ideas about areas to focus on in deep dive based on her feedback

You shall work with the interviewer to identify and prioritize components in the architecture. It is worth stressing that every interview is different. Sometimes, the interviewer may give off hints that she likes focusing on high-level design. Sometimes, for a senior candidate interview, the discussion could be on the system performance characteristics, likely focusing on the bottlenecks and resource estimations. In most cases, the interviewer may want you to dig into details of some system components. For URL shortener, it is interesting to dive into the hash function design that converts a long URL to a short one. For a chat system, how to reduce latency and how to support online/offline status are two interesting topics.

Time management is essential as it is easy to get carried away with minute details that do not demonstrate your abilities. You must be armed with signals to show your interviewer. Try not to get into unnecessary details. For example, talking about the EdgeRank algorithm of Facebook feed ranking in detail is not ideal during a system design interview as this takes much precious time and does not prove your ability in designing a scalable system.

Example

At this point, we have discussed the high-level design for a news feed system, and the interviewer is happy with your proposal. Next, we will investigate two of the most important use cases:

1. Feed publishing
2. News feed retrieval

Figure 3 and Figure 4 show the detailed design for the two use cases, which will be explained in detail in the "Design A News Feed System" chapter.

步骤 3 - 深入设计

在这一步，您和面试官应该已经达成以下目标：

• 就整体目标和功能范围达成一致
• 为整体设计绘制了一个高层次的蓝图
• 从面试官处获得了关于高层设计的反馈
• 根据反馈对需要深入探讨的区域有了一些初步想法

您应与面试官合作，识别并优先考虑架构中的关键组件。需要强调的是，每场面试都是不同的。有时，面试官可能会暗示她喜欢专注于高层次设计。而在面试高级候选人时，讨论可能集中在系统性能特性上，尤其是瓶颈和资源估算。在大多数情况下，面试官可能希望您深入探讨某些系统组件的细节。例如，在设计URL缩短服务时，可以深入探讨将长URL转换为短URL的哈希函数设计。而在聊天系统中，如何减少延迟以及如何支持在线/离线状态则是两个值得探讨的主题。

时间管理非常重要，因为很容易陷入无关的细节而无法展示您的能力。您需要展示面试官想要看到的信号，避免进入不必要的细节。例如，详细讨论Facebook推送排序中的EdgeRank算法在系统设计面试中并不理想，因为这会占用宝贵的时间，且并不能证明您在设计可扩展系统方面的能力。

示例

到此为止，我们已经讨论了新闻推送系统的高层设计，并且面试官对您的方案感到满意。接下来，我们将深入研究两个最重要的用例：

1. 推送发布
2. 新闻推送获取

图3和图4展示了这两个用例的详细设计，具体内容将在“设计新闻推送系统”一章中详细说明。

Step 4 - Wrap up

In this final step, the interviewer might ask you a few follow-up questions or give you the freedom to discuss other additional points. Here are a few directions to follow:

• The interviewer might want you to identify the system bottlenecks and discuss potential improvements. Never say your design is perfect and nothing can be improved. There is always something to improve upon. This is a great opportunity to show your critical thinking and leave a good final impression.
• It could be useful to give the interviewer a recap of your design. This is particularly important if you suggested a few solutions. Refreshing your interviewer’s memory can be helpful after a long session.
• Error cases (server failure, network loss, etc.) are interesting to talk about.
• Operation issues are worth mentioning. How do you monitor metrics and error logs? How to roll out the system?
• How to handle the next scale curve is also an interesting topic. For example, if your current design supports 1 million users, what changes do you need to make to support 10 million users?
• Propose other refinements you need if you had more time.

To wrap up, we summarize a list of the Dos and Don’ts.

Dos

• Always ask for clarification. Do not assume your assumption is correct.
• Understand the requirements of the problem.
• There is neither the right answer nor the best answer. A solution designed to solve the problems of a young startup is different from that of an established company with millions of users. Make sure you understand the requirements.
• Let the interviewer know what you are thinking. Communicate with your interview.
• Suggest multiple approaches if possible.
• Once you agree with your interviewer on the blueprint, go into details on each component. Design the most critical components first.
• Bounce ideas off the interviewer. A good interviewer works with you as a teammate.
• Never give up.

Don’ts

• Don't be unprepared for typical interview questions.
• Don’t jump into a solution without clarifying the requirements and assumptions.
• Don’t go into too much detail on a single component in the beginning. Give the high-level design first then drills down.
• If you get stuck, don't hesitate to ask for hints.
• Again, communicate. Don't think in silence.
• Don’t think your interview is done once you give the design. You are not done until your interviewer says you are done. Ask for feedback early and often.

步骤 4 - 总结

在最后一步，面试官可能会问您一些后续问题，或让您自由讨论其他补充内容。以下是一些可以遵循的方向：

• 面试官可能会希望您识别系统瓶颈并讨论潜在的改进。不要说您的设计是完美的、无需改进。总有改进的空间。这是展示批判性思维并留下良好最后印象的好机会。
• 向面试官简要回顾您的设计可能会很有帮助。如果您提出了多个解决方案，回顾一下设计思路尤其重要。经过长时间的讨论后，这样做能帮助面试官回忆重点。
• 讨论错误情况（服务器故障、网络中断等）可能很有趣。
• 运营问题也值得一提。您如何监控指标和错误日志？如何上线系统？
• 讨论如何应对下一阶段的扩展也是个有趣的话题。例如，如果当前设计支持100万用户，您需要做出哪些更改来支持1000万用户？
• 提出在更多时间下可能进行的其他优化。

为了总结，我们列出了一些应做和不应做的事项。

应做的事项

• 始终询问澄清问题。不要假设您的假设是正确的。
• 理解问题的需求。
• 这里没有唯一正确或最佳的答案。为初创公司设计的解决方案与为拥有数百万用户的成熟公司设计的方案不同。确保您理解需求。
• 让面试官了解您的思路，与面试官沟通。
• 如果可能，提出多个方法。
• 一旦您和面试官就蓝图达成一致，深入讨论每个组件。优先设计最关键的组件。
• 向面试官探讨想法。优秀的面试官会像队友一样与您合作。
• 永不放弃。

不应做的事项

• 不要对典型的面试问题毫无准备。
• 在没有澄清需求和假设的情况下，不要急于提出解决方案。
• 不要一开始就深入单一组件的细节。先给出高层设计，然后再深入细节。
• 如果卡住了，不要犹豫请求提示。
• 再次强调，与面试官沟通，不要默默思考。
• 当您给出设计后，面试并未结束。只有当面试官表示结束时，才算真正完成。尽早且频繁地请求反馈。

Time allocation on each step

System design interview questions are usually very broad, and 45 minutes or an hour is not enough to cover the entire design. Time management is essential. How much time should you spend on each step? The following is a very rough guide on distributing your time in a 45-minute interview session. Please remember this is a rough estimate, and the actual time distribution depends on the scope of the problem and the requirements from the interviewer.

Step 1 Understand the problem and establish design scope: 3 - 10 minutes

Step 2 Propose high-level design and get buy-in: 10 - 15 minutes

Step 3 Design deep dive: 10 - 25 minutes

Step 4 Wrap: 3 - 5 minutes

每个步骤的时间分配

系统设计面试问题通常非常广泛，而45分钟或一小时的时间并不足以涵盖整个设计。时间管理至关重要。那么每个步骤应该花多少时间呢？以下是在45分钟面试中分配时间的粗略指南。请记住，这是一个大致的估算，实际的时间分配将取决于问题的范围和面试官的要求。

• 步骤 1 理解问题并确定设计范围：3 - 10分钟
• 步骤 2 提出高层设计并获得认可：10 - 15分钟
• 步骤 3 深入设计：10 - 25分钟
• 步骤 4 总结：3 - 5分钟

https://www.youtube.com/watch?v=i7twT3x5yv8&t=230s