背完 28 套架构，为什么系统设计面试还是答不好

凌晨 2 点，我随手翻开一道系统设计题。

设计一个通知系统。

脑子里的第一反应很熟悉，API Gateway、Kafka、Redis、数据库，再补一张箭头很多的架构图。组件一个没少，真正被问到「每天多少请求」「消息丢了怎么办」「为什么不用同步调用」时，思路还是会卡住。

这大概是系统设计面试最容易掉进去的坑。背了很多架构，还是不会把一个模糊问题推到可执行的设计。

我把 liquidslr/system-design-notes 的 28 章扫了一遍。仓库抓取时有 10,531 个 Star、2,109 个 Fork，里面放了 29 份 Markdown、392 张图片，正文大约 36 万字节。数字挺大，但说真的，它最有用的部分不是又给你 28 张标准答案。

是那套反复出现的答题顺序。

这不是一本新的系统设计教材

先把定位说清楚。

仓库 README 明确写着，内容来自 Alex Xu 的《System Design Interview》两卷书，而且仍是 work in progress。它更像一份按章节整理的复习笔记。前 3 章讲扩容、粗略估算和面试框架，后面 25 章从限流器一路做到证券交易所。

目录跨度确实够大。URL 短链、聊天、新闻流、Google Drive 属于常见题，后半段又塞进了分布式消息队列、监控告警、广告点击聚合、支付、数字钱包和对象存储。

坦白讲，如果你第一次学 CAP、Quorum 或 Saga，直接啃这套笔记会有点吃力。很多地方只有定义、图和结论，推导过程仍得回书里补。可如果你已经学过一轮，想把零散知识重新串起来，它比从 28 个浏览器标签里找资料舒服得多。

它是复习索引，不是原书替代品。

28 道题，其实一直在重复四个动作

仓库第 3 章给出了一套 45 分钟面试框架。需求和范围用 3 到 10 分钟，高层设计用 10 到 15 分钟，关键模块深挖用 10 到 25 分钟，最后留 3 到 5 分钟收口。

这个时间分配看着普通，放回后面 25 道题里就有意思了。它们不断重复同一条推演链。

先把题目削小

「设计证券交易所」听着能聊一整天。第 28 章先放下撮合引擎，逐个问交易什么证券、支持哪些订单、是否有盘后交易、一天多少订单。范围最后收敛到约 100 个标的、每天 10 亿笔订单、只处理限价单和正常交易时段。

你想想看，这一步做完，后面的组件才有讨论价值。否则你画的只属于自己的想象，和题目没多大关系。

再让数字决定设计

第 2 章用 Twitter 做粗略估算。3 亿月活、50% 日活、每人每天 2 条推文，平均写入约 3,500 QPS，峰值按两倍算到约 7,000 QPS。10% 推文带 1 MB 媒体，保留 5 年，存储量会到约 55 PB。

我一直觉得，背出多少中间件拉不开差距。把「很多用户」换成吞吐、带宽和存储，才是在做设计。数字不要求精确，它负责排除明显不成立的方案。

第 28 章也做了同样的事。每天 10 亿笔订单集中在 6.5 小时交易时段，平均约 43,000 QPS，峰值按 5 倍估到 215,000 QPS。于是撮合链路必须压延迟，报表链路却可以异步处理。关键路径就是这么算出来的，凭感觉圈不准。

然后只画能解释取舍的高层图

限流器章节先比较客户端、服务端和 API Gateway 三个放置位置，再对 Token Bucket、Leaking Bucket、Fixed Window、Sliding Window Log 和 Sliding Window Counter 做取舍。Redis 放在后面，只负责承接计数器的读写。

酒店预订那章也一样。真正难的不是画出用户服务、酒店服务和预订服务，而是同一个用户点两次怎么办，多个人抢最后一间房怎么办。前者靠幂等键，后者要讨论数据库约束、悲观锁和乐观锁。

组件名只是名词。

取舍才是回答。

最后沿故障路径往下钻

数字钱包章节从 2PC 走到 TC/C 和 Saga，接着讨论补偿事务、乱序执行、Event Sourcing、CQRS 与 Raft。证券交易所则把入站订单和出站成交都盖上序列号，让撮合结果可确定、可重放。

其实吧，这些章节反复在问同一件事。节点挂了、消息重复了、顺序乱了，系统还能不能恢复到一个说得清的状态。

面试官要看的深度，通常藏在这里。

和另外两套热门资料怎么选

系统设计资料很多，没必要全都从第一页读到最后一页。我把它和另外两个常见仓库放在一起看，区别挺清楚。

反正我的选法很简单。没学过就先用课程补基础，知识点散就用 Primer 建地图，读完 Alex Xu 后想刷案例，再回到 system-design-notes。

别拿三套资料同时开荒。收藏夹会很充实，脑子不会。

我更推荐把它当成闭卷题库

README 只让你按章节阅读，我倒是更推荐一种「四格反向演练法」。它不在仓库说明里，但更能榨出这 28 章的价值。

每次只看章节标题，先别打开答案。拿一张纸分成四格，分别写范围、数字、关键路径和故障恢复。

以消息队列为例，范围里写点对点还是发布订阅，数字里估消息大小、吞吐和保留时间，关键路径写生产、路由、持久化与消费，故障恢复则回答 ACK、重试、重复消费和 Broker 宕机。

限时 8 分钟。

写完再打开对应章节，只对照两件事。你漏掉了哪一个决定，以及你的决定有没有数字支撑。不要抄整张架构图，也别把组件名记成标准答案。

连续练 5 道题后，你会发现题面一直在变，骨架没怎么变。这个方法我愿意叫它「决策链复习法」。复习的单位从知识点变成一条可以复述的设计路径。

一万多个 Star 没替它补上的东西

这份笔记好用，但有几个边界得提前知道。

仓库根目录没有 LICENSE。README 又明确说明笔记基于商业出版物，两者放在一起看，最稳妥的使用方式是个人学习和链接引用，不要默认把文字与 392 张图片当成可自由再发布的开放素材。

维护也很集中。贡献记录里，主要作者有 32 次提交，另外两位贡献者各 1 次。最后一次推送发生在 2026 年 6 月 2 日，没有 Release，也没有 Tag。README 仍写着 work in progress，这句不是客套话。

仓库里还留着一些复习时会绊一下的小问题。PR #4 正在修第 1 章的英文笔误，PR #3 想给 28 章补上一页和下一页导航，但两条 PR 目前都没合并。第 28 章关于 Event Sourcing 的链接还指向不存在的 ../chapter28。

说真的，这些问题不妨碍你理解系统设计，却提醒了一个事实。它是个人笔记仓库，没有经过正式教材那样的编辑、校对和版本发布。遇到公式、协议细节和时效性数据，最好回原书、论文或官方文档核一次。

带走的不是架构图，是决策链

系统设计面试没有一张图能包打天下。相同的新闻流，读多写少时会偏向 fan-out on write，大 V 粉丝量太高又可能改成混合策略。相同的限流需求，允许突发流量和要求严格均匀出流，算法选择也会不同。

所以呢，system-design-notes 最适合拿来反复练习同一条决策链，28 个答案只是材料。

先问清范围，再用数字压缩方案空间。画出关键路径后，只挑最影响成败的部分深挖，最后沿故障路径检查系统能否恢复。

图可以忘。

这条链得留下。