系统设计面试框架

一句话

你以为系统设计面试考的是「你会不会设计系统」，其实它考的是：在信息严重不足、时间只有 45 分钟、对面还坐着一个人的条件下，你怎么把一个含糊的问题变成一个可做的问题。原书把这件事说得很直白——这是一次「两个同事协作解决开放问题」的模拟，最终那张图远没有你走到它的那段过程重要。这一章不教任何技术，它只给一个顺序；而这个顺序，恰好就是真实世界里做一次设计评审的顺序。

Glossary · 术语表

坐标

这是卷一 Part I「方法与基础」的收尾章，也是全书的转轴：Ch1 给零件（缓存、从库、负载均衡、分片）、Ch2 给尺子（QPS、存储、可用性的量级），Ch3 给的是把零件和尺子组织起来的顺序。它之后的十二个案例章——限流器、短网址、爬虫、信息流、聊天、YouTube、Google Drive——没有一章引入新方法，每一章都是这四步跑一遍的实录。对应到现实里也很具体：这四步就是一份设计文档 / 设计评审会的骨架，只是把两周压缩进了 45 分钟。

这章要解决什么

面试官说「设计一个 Twitter」，然后闭嘴。这五个字里没有规模、没有功能范围、没有约束——这是故意的。原书点破了原因：题目开放且含糊，因为公司里真实的题目就长这样。含糊本身就是考题的一部分。

不解决会怎样？三种死法，每一种都很典型。

一、直接开答。原书写得很不客气：不加思索地快速给出答案不会给你任何加分；这不是知识竞赛。更糟的是你答的可能根本不是这道题——面试官心里那个 Twitter 是日活五千万、读写比大约 100:1 的系统，你却按一个日活一万的内部工具做了四十分钟。差三个数量级的两道题，正确答案毫无交集。

二、广度铺满、深度为零。八个方框都画上了，可每个框都只有一个名字。你证明了自己听说过这些组件，没证明用过。

三、一头扎进去。第 3 分钟就在推敲哈希环上该放多少个虚拟节点，而需求还没问清。原书特意举了个例子：在一道本意考「能不能扛住大规模」的题里，花大段时间讨论 BFS 与 DFS 的取舍，是一个明确的负信号——它说明你不知道对方在看什么。

再加一个硬约束：45 分钟。一场标准的现场轮次 45–60 分钟，掐掉自我介绍和最后的反问，真正属于设计的通常只有四十分钟出头。在这个预算下，没有顺序 = 一定会整块整块地漏——不是漏细节，是漏掉「非功能需求」或「收尾」这样一整个维度。所以这一章要交付的能力只有一个：一套能套在任何题目上的固定顺序，外加每一步该花多少分钟。

核心内容，讲透

第一步：理解问题、确立设计边界（3–10 分钟）

原书对这一步的要求近乎苛刻：不要立刻回答。慢下来，深想，问问题。它把「面试不是知识竞赛」写在旁边，就是要堵住抢答的冲动——抢答没有加分，只有风险。

该问什么？原书给了两层。第一层是任何题都适用的四问：要建的具体功能有哪些？有多少用户？公司预期扩张有多快？现有技术栈是什么、有哪些现成服务可以直接用？最后一问最容易被跳过，却最贴近真实工作——真实的设计从来不是在白纸上做的。

第二层是把四问落到具体题目。原书以「设计信息流系统」为例，问出来的是：是移动 App、网页还是两者都要？最重要的功能是哪几个？信息流按时间倒序排，还是按权重排（比如好友的帖子权重更高）？一个用户最多多少好友？流量量级多大？帖子里能不能带图片和视频？

注意这几个问题的共同性质：每一个的不同答案都会改掉架构，而不只是改掉参数。「按权重排」意味着要多一套排序服务和特征存储；「能带视频」意味着转码流水线、对象存储和 CDN——这一条本身就够是另一道题了。反过来说，一个问题如果不同答案不会改变你的设计，它就不该占用这十分钟。

这一步的产出不是那些问题，是一份写在白板角上、双方都认可的清单：功能范围、规模假设、明确不做的部分。写下来的价值和 Ch2 一样——它让后面每一句话都有据可依，也让对方能指着其中一条说「这条改一下再看」。

第二步：提出高层设计并取得认同（10–15 分钟）

这一步的目标不是画对，是画到双方都点头。原书用了 buy-in（取得认同）这个词，它就是这一步的全部重点：把面试官当队友，边画边征求反馈，而不是自己闷头画完再展示成果。

具体做三件事。一是画方框图：客户端、API、Web 服务器、数据存储、缓存、CDN、消息队列——用最少的框把数据的进出路径描出来。二是做一次粗略估算（Ch2 那套），当场验证这张图撑不撑得住第一步定下的量级；原书特别提醒，算的时候要说出声。三是和面试官商量要不要展开 API 端点和数据库表结构——这是可协商的选项，不是必答项：有的面试官想看接口签名，有的觉得那是浪费时间。

这一步最容易犯的错不是画得不好，是画完不停。停下来问一句「这个方向你觉得可以吗」，成本十秒；不问的代价，是后面二十分钟全部走在一条对方并不认可的路上。

第三步：深挖（10–25 分钟）

走到这里，四件事已经具备：目标与功能范围谈定了、高层蓝图画出来了、拿到了反馈、也大致知道该重点看哪里。这一步就是和面试官一起挑出该挖的组件，然后挖透。

挖哪一块由题目决定，原书给了两个对照例子：短网址服务的重点在哈希函数——怎么把长 URL 映射成短 key、碰撞怎么处理；聊天系统的重点则在延迟怎么压下来、在线与离线状态怎么维护。同一套流程，落点完全不同，这正是「框架」和「模板」的区别。

这一步真正的技巧是时间管理。原书直接点名一种失分方式：陷入不必要的细节。10–25 分钟这个预算，够挖两个组件，不够挖五个。所以挑之前先问一句「你更想看存储这块，还是扇出这块」——这一问省下的常常有五分钟，而五分钟在这个预算里是八分之一场。

挖的时候，一个组件讲三件事就够了：怎么做、为什么这么做、代价是什么。第三件最见功力——只讲「怎么做」的人像在背书，讲得出代价的人才像做过。同样说「用缓存」，停在这里是背书；说到「缓存挂掉的瞬间全部流量会直接打到数据库上，所以要么预热要么加熔断」，才是深挖。

第四步：收尾（3–5 分钟）

原书列的收尾动作有五件：

• 找瓶颈：这套系统最先撑不住的地方在哪，接下来该往哪里改。
• 快速复述一遍设计：尤其在长时间深挖之后，把整体重讲一遍能帮面试官刷新记忆——而记忆决定他一小时后写下的评价。
• 错误场景：某台服务器挂了怎么办、网络断了怎么办。
• 运维：怎么监控、看哪些指标、怎么发布上线。
• 下一档规模：现在能扛一百万用户，到一千万时要改哪里。

这五件的共同点是：它们谈的全是「之后」。很多人把这三分钟当客套，其实它是全场性价比最高的三分钟——前面四十分钟你在证明你会设计，这三分钟你在证明你知道设计完之后会发生什么，而后者正是「会做题」和「上过线」之间那道分水岭。原书还有一句常被忽略的话：设计讲完不等于结束，面试官说结束才是结束；要早、要频繁地征求反馈。

关键权衡与选型

这一章没有技术选型，但有三组真实的权衡：时间怎么分、广度与深度怎么配、什么时候该承认不会。

表 1 · 四步：产出、预算、最常见的失误与自救话术

表 2 · 原书的 Dos & Don'ts，折成一张对照表

表 3 · 三组真实权衡：怎么选，以及选错的代价

表 3 最后一行值得单独说一句。很多人以为说「我不确定」是失分，其实相反：面试官几乎一定比你更懂这块，编造会被当场识别，而识别出的不是「不懂」，是「不可信」。可信度一旦掉了，前面讲得再好也救不回来。

为什么重要 / 落到真实系统

这四步不是为面试发明的，它是一次真实设计评审的压缩版。把时间尺度从 45 分钟拉到两周，每一步都能在真实工程里找到对应物：第一步 = 需求与非目标（non-goals）的确认——Amazon 的 Working Backwards 把它推到极致，动工前先按「产品已发布」的样子写好新闻稿与 FAQ，打动不了客户的想法在派工程师之前就被砍掉；第二步 = 设计文档里的「架构概览」那一节，以及那场让人点头的评审会；第三步 = 设计文档最厚的那部分，关键决策与备选方案对比；第四步 = 上线前的清单：监控、告警、回滚、容量。这也是为什么这一章值得单独学：它的收益不止于拿 offer。

易错点与争议

• 红旗一：过度设计。原书的措辞很重——过度设计是许多工程师的一种真实的病，他们沉迷于设计的纯粹性而无视权衡，且往往意识不到过度设计的复合成本。面试里的典型表现是给一个日活一万的服务上多机房多活。
• 红旗二、三：思路狭窄与固执。前者是任何题都往自己熟的那一套上套；后者是听不进反馈——这条最致命，因为它直接否掉了这一章的前提：这是一次协作。
• 在沉默中思考。面试官看不到你脑子里的东西。想两分钟不说话，在评价里就是两分钟的空白。
• 把框架背成台词。这是这套方法最常见的走样：机械地问一串与题无关的问题（给一个内部批处理任务问「移动端还是网页端」），或者背完四步却答不出任何一处代价。问题要服务于设计判断，不是为了走流程——面试官分得出「在澄清」和「在表演澄清」。
• 适用范围的局限。这本书 2020 年出版，四步法针对的是大厂通用后端设计轮次。有几类轮次它适配不良：ML 系统设计（要谈数据来源、特征、离线在线一致性、评估指标）、前端系统设计，以及以「造轮子内部构造」为题的轮次（如卷二 Ch4 自己实现一个消息队列）。骨架仍然成立，但第一步该问的清单完全不同——照搬通用四问会显得答非所问。
• 一点争议。45 分钟白板能不能测出真实设计能力，业界一直有争论：反方认为它测的是「面试表现」而非工程能力，会系统性地偏向刷过题的人。这个批评是成立的，但它针对的是这种考试形式，不是这套框架——在既定形式下，有顺序仍然显著优于没顺序。更何况顺序本身在真实工作里也用得上，这是它比刷题更值的地方。

要点