如果你点开这个项目名说明你多半也在准备系统设计类的面试或者正在带团队做方案评审。我维护的这套system-design-notes已经有三年多累计整理了几十个高频场景短链接、信息流、秒杀、IM、搜索引擎、推荐系统……它救过我两次一次是跳槽时遇到的全链路设计题一次是我们内部做高可用改造我直接把笔记里的推送链路画成了草图。这篇博文就把这套笔记从数据结构到思考方式完整拆给你如果你也想建一套自己的 system design 知识库可以直接照着搭。我始终觉得系统设计最难的从来不是背方案而是面对一个模糊问题能一步步把范围、瓶颈、取舍讲清楚。system-design-notes的底层逻辑也是围绕这件事展开的它不是高频考点速记更像一本“决策记录本”。接下来我会把笔记的规划方式、核心知识点、一道完整题目拆解以及踩过的坑全部放出来。1. 为什么我会维护一份 system-design-notes1.1 从面试痛点说起大概六年前我第一次准备系统设计面试当时手忙脚乱地在网上收藏了一堆架构图今天看一个“如何设计秒杀系统”明天看一个“如何设计打车平台”。看得越多越心虚因为每篇文章口径都不一样有的说 Kafka 能抗百万 QPS有的说 MySQL 单表只能到几千还有的说 Redis 做分布式锁一定要用 Redlock。没有一个统一坐标系最后面试官问“你这里为什么选消息队列而不是直接调用”我只会重复文章里的结论根本说不出背后的取舍。后来我想明白一个问题系统设计没有唯一标准答案只有在一定约束下的合理选择。所以我决定放弃“收集文章”改成“记录决策”。每一道题我都用同一套模板写一遍时间久了不同题目之间的共性开始浮现这套笔记才真正变成我自己的东西。现在你看到的system-design-notes最早的 commit 就是我给自己立的一个规矩任何一道设计题不写出“容量估算”和“权衡记录”这两节就不算做完。1.2 笔记仓库的核心定位这个仓库不是给别人看的是给三个月后的自己看的。所以它的第一原则是“能快速唤起记忆”而不是“写得多完整”。我见过很多人的笔记像论文一样长篇大论结果回看时根本找不到重点。我给自己定的格式是每道题一页 Markdown控制在 800 到 1500 字超过的部分全是废话。第二个原则是“结论都要能反推”。比如笔记里写了“短链接使用 Base62 编码生成短码”旁边必须补一句“因为纯随机字符串撞库概率高且需要额外去重而发号器方案天然自增可以顺便解决分片 ID 冲突”。没有这一层笔记就退化成名词解释。第三个原则是“定期淘汰”。每过两三个月我会重读一遍旧笔记把已经过时的部分删掉比如某些组件的新版本特性、某条不再适用的容量经验值。系统设计知识更新很快笔记应该是活文档不是化石。2. 笔记库的整体设计与组织方式2.1 目录结构如何规划我最初的目录是按公司面试题分类的比如“字节”“阿里”“美团”结果发现同一个知识点在每家公司题目里都会出现维护起来全是重复。后来改成按“场景 基础能力”双维度组织效果好了很多。system-design-notes/ ├── scenarios/ # 场景题按业务域拆 │ ├── url-shortener.md │ ├── news-feed.md │ ├── instant-messaging.md │ ├── flash-sale.md │ ├── search-engine.md │ └── rate-limiter.md ├── building-blocks/ # 通用组件单独成篇 │ ├── unique-id-generator.md │ ├── distributed-cache.md │ ├── message-queue.md │ ├── distributed-lock.md │ └──>
如果你点开这个项目名说明你多半也在准备系统设计类的面试或者正在带团队做方案评审。我维护的这套system-design-notes已经有三年多累计整理了几十个高频场景短链接、信息流、秒杀、IM、搜索引擎、推荐系统……它救过我两次一次是跳槽时遇到的全链路设计题一次是我们内部做高可用改造我直接把笔记里的推送链路画成了草图。这篇博文就把这套笔记从数据结构到思考方式完整拆给你如果你也想建一套自己的 system design 知识库可以直接照着搭。我始终觉得系统设计最难的从来不是背方案而是面对一个模糊问题能一步步把范围、瓶颈、取舍讲清楚。system-design-notes的底层逻辑也是围绕这件事展开的它不是高频考点速记更像一本“决策记录本”。接下来我会把笔记的规划方式、核心知识点、一道完整题目拆解以及踩过的坑全部放出来。1. 为什么我会维护一份 system-design-notes1.1 从面试痛点说起大概六年前我第一次准备系统设计面试当时手忙脚乱地在网上收藏了一堆架构图今天看一个“如何设计秒杀系统”明天看一个“如何设计打车平台”。看得越多越心虚因为每篇文章口径都不一样有的说 Kafka 能抗百万 QPS有的说 MySQL 单表只能到几千还有的说 Redis 做分布式锁一定要用 Redlock。没有一个统一坐标系最后面试官问“你这里为什么选消息队列而不是直接调用”我只会重复文章里的结论根本说不出背后的取舍。后来我想明白一个问题系统设计没有唯一标准答案只有在一定约束下的合理选择。所以我决定放弃“收集文章”改成“记录决策”。每一道题我都用同一套模板写一遍时间久了不同题目之间的共性开始浮现这套笔记才真正变成我自己的东西。现在你看到的system-design-notes最早的 commit 就是我给自己立的一个规矩任何一道设计题不写出“容量估算”和“权衡记录”这两节就不算做完。1.2 笔记仓库的核心定位这个仓库不是给别人看的是给三个月后的自己看的。所以它的第一原则是“能快速唤起记忆”而不是“写得多完整”。我见过很多人的笔记像论文一样长篇大论结果回看时根本找不到重点。我给自己定的格式是每道题一页 Markdown控制在 800 到 1500 字超过的部分全是废话。第二个原则是“结论都要能反推”。比如笔记里写了“短链接使用 Base62 编码生成短码”旁边必须补一句“因为纯随机字符串撞库概率高且需要额外去重而发号器方案天然自增可以顺便解决分片 ID 冲突”。没有这一层笔记就退化成名词解释。第三个原则是“定期淘汰”。每过两三个月我会重读一遍旧笔记把已经过时的部分删掉比如某些组件的新版本特性、某条不再适用的容量经验值。系统设计知识更新很快笔记应该是活文档不是化石。2. 笔记库的整体设计与组织方式2.1 目录结构如何规划我最初的目录是按公司面试题分类的比如“字节”“阿里”“美团”结果发现同一个知识点在每家公司题目里都会出现维护起来全是重复。后来改成按“场景 基础能力”双维度组织效果好了很多。system-design-notes/ ├── scenarios/ # 场景题按业务域拆 │ ├── url-shortener.md │ ├── news-feed.md │ ├── instant-messaging.md │ ├── flash-sale.md │ ├── search-engine.md │ └── rate-limiter.md ├── building-blocks/ # 通用组件单独成篇 │ ├── unique-id-generator.md │ ├── distributed-cache.md │ ├── message-queue.md │ ├── distributed-lock.md │ └──>
