系统设计 · 课程
把模糊的题目，画成能落地的系统。
一门免费的系统设计面试课：先学 45 分钟的五步答题框架，再用经典案例逐步练习需求澄清、容量估算、API、高层设计、深挖与权衡；另有面向对象设计、并发、ML 系统设计，以及 Kafka、Redis 等关键技术、通用设计模式、LLD 案例库和 API 设计的选读章节，每章附选择题测验。
必修章节约 3 小时 3 分钟，选读章节约 3 小时 2 分钟。 容量估算练习：10 个场景，算 QPS、存储、带宽和机器数
系统设计：框架与案例
- 第 1 章第 1 章：系统设计面试框架系统设计面试通常 45–60 分钟，题目往往只有一句话：“设计一个短链接服务”“设计 Twitter 首页 Feed”。这类题没有标准答案。面试官主要看三件事：你能不能把模糊的问题拆清楚，能不能在约束下做出合理取舍，能不能边做边把思路讲明白。
- 第 2 章第 2 章：系统设计的基本构件绝大多数系统设计题都由同一批“积木”拼成。面试中不需要讲清每个组件的全部细节，但需要知道三件事：它解决什么问题、要付出什么代价、什么时候不该用它。
- 第 3 章案例 1：短链接服务短链接是系统设计面试里最常见的“热身题”。业务逻辑几乎为零，所以面试官真正考的是：你能不能把一个简单需求拆清楚，算清读写比，讲明白 ID 怎么生成，以及热路径怎么做到毫秒级。
- 第 4 章案例 2：分布式限流器限流器看起来是一道“组件题”，考察面却很全：算法选择、并发原子性、分布式一致性，以及故障时到底该放行还是拒绝。
- 第 5 章案例 3：信息流与时间线Twitter 首页、朋友圈、Instagram 关注流本质上是同一道题：用户关注了一批人，打开首页时要很快看到这些人的最新内容。难点不在发帖本身，而在于“一个人发帖，成千上万人的首页都要跟着变”。
- 第 6 章案例 4：设计即时通讯系统（类 WhatsApp）聊天系统是面试里出现频率最高的题之一。表面上很简单：A 发一条消息，B 收到。真正要讲清楚的是三件事：长连接怎么管、消息怎么做到不丢、不乱、不重、用户离线后怎么补齐。下面按“需求 → 估算 → 接口 → 架构 → 深挖 → 故障”走一遍。
- 第 7 章案例 5：设计网约车派单系统（类 Uber）网约车这道题的重点不在“下单”，而在两件事：海量司机位置的高频写入和就近查询，以及派单时绝不能把一个司机同时派给两个乘客。前者考地理索引，后者考并发控制。
- 第 8 章案例 6：设计通知系统通知系统看起来像个转发器，实际上是一道可靠性工程题。上游业务只说一句“告诉用户 X，他的包裹发货了”，通知系统要决定：发不发、走哪个渠道、什么时候发、失败了怎么办、会不会发重。
- 第 9 章案例 7：设计视频流平台（类 YouTube）视频平台是面试里的高频题。它的难点不在 QPS，而在两件事：海量存储和出口带宽。答题时先把这两个数算出来，后面的设计（对象存储、转码、CDN）就都有了依据。
- 第 10 章案例 8：设计网络爬虫爬虫看起来只是“下载网页、找链接、继续下载”的循环。但放到数十亿网页的规模上，难点就变成了三件事：不把别人的网站打挂（礼貌性）、不重复抓取（去重）、不掉进陷阱（鲁棒性）。
- 第 11 章案例 9：设计分布式键值存储这道题考的是分布式系统的基本功：分区、复制、一致性、故障处理，再加上单机存储引擎。它没有唯一的标准答案，关键在于每个选择都能说清楚代价。下文以 Dynamo 风格（高可用、一致性可调）为主线，最后再对比基于 Raft 的强一致方案。
- 第 12 章案例 10：支付系统与记账账本假设每天 1000 万笔支付：平均约 115 TPS，峰值按 10 倍算约 1,200 TPS。每笔支付在账本里产生 2～4 条分录，峰值约 5,000 次写入/秒。一台调优良好的关系型数据库主库就扛得住，分片更多是为了隔离和未来增长。
- 第 13 章案例 11：搜索自动补全（Typeahead）结论：整份索引放得进单机内存。扩展主要靠加副本扛 QPS，未必需要分片。
- 第 14 章案例 12：票务抢购系统（类 Ticketmaster）结论：难点不在存储容量，而在短时间内对同一小批数据的激烈争抢。
面向对象设计（LLD）
- 第 15 章OOD 面试方法论：45 分钟的节奏低层设计（LLD），也常叫 OOD（Object-Oriented Design）面试，题目通常是“设计一个停车场”“设计一个 LRU 缓存”“设计电梯系统”。它和高层系统设计（HLD）的关注点完全不同：
- 第 16 章SOLID 原则在面试里的真实用法几乎每个候选人都能背出 SOLID 五个字母，但面试官真正想看的是：你的类图里哪里体现了这些原则，以及你什么时候选择不用。下面每条原则都配一个面试中真实会出现的例子。
- 第 17 章LLD 案例 1：停车场停车场是 LLD 的“Hello World”，正因为人人都准备过，面试官会更在意细节。先和面试官对齐：
- 第 18 章LLD 案例 2：带 TTL 的 LRU 缓存基础版是 LeetCode 146：容量固定，get / put 都要 O(1)，满了淘汰最久未使用的条目。面试中常见的加码是：每个条目带过期时间（TTL），过期后对外不可见。
- 第 19 章LLD 案例 3：电梯系统停车场和 LRU 的核心是数据结构，电梯题的核心是状态和调度：电梯在时间上不断变化，请求随时到达，多部电梯还要协作。很多候选人类图画得不错，却说不清“电梯此刻该往哪走”。
并发编程
ML 系统设计
- 第 23 章ML 系统设计框架ML 系统设计面试（常见于机器学习工程师岗位）同样是 45–60 分钟、一句话的题目，比如“设计视频首页推荐”“设计支付欺诈检测”。和传统系统设计相比，面试官更关心：你能不能把业务目标翻译成可以训练的 ML 任务，标签从哪里来，用什么特征，怎么离线和线上评估，模型上线以后怎么提供服务、怎么发现它变…
- 第 24 章ML 案例 1：推荐排序（视频首页）推荐是 ML 系统设计里最常见的题。“设计视频 App 的首页推荐”听起来是一个模型，实际上是一条多阶段漏斗：在 200 毫秒内，从几千万个视频里挑出用户最可能看完、最不会反感的二十几个。面试官主要看三点：漏斗每一层为什么这样设计，优化目标和标签怎么定，以及怎么避免系统只会推它推过的东西。
- 第 25 章ML 案例 2：电商搜索排序搜索排序和推荐很像，都是从海量物品里挑出一个有序列表，但多了一个硬约束：结果必须和查询词相关。用户搜“跑步鞋”，排第一的却是销量最高的电饭煲，模型再懂用户也没用。这道题考的是检索和排序怎么分工，怎么从点击日志里提取可靠的相关性信号，以及怎么评估一个排序。
- 第 26 章ML 案例 3：广告点击率预估在广告系统里，模型预测的点击率（pCTR）不只用来排序，还直接决定钱：按点击计费的广告按“出价 × pCTR”排名，扣费也和 pCTR 有关。所以这道题和推荐最大的不同是：预测值必须校准，0.02 就得真的意味着 2% 的点击概率。另外，数据量极大、正样本极少、广告和用户兴趣变化很快，模型需要频繁…
- 第 27 章ML 案例 4：支付欺诈检测欺诈检测要在一笔支付的授权流程里，用几十毫秒判断它是不是盗刷。它和推荐、广告有三点明显不同：错误的代价不对称（漏掉一笔欺诈和误拒一个正常用户，损失完全不同），标签要等几周甚至几个月，以及对手会主动适应你的模型。
关键技术（选读）
- 第 28 章关键技术：KafkaKafka 是一个分布式的、只追加的日志。生产者把消息写到日志末尾，消费者按自己的进度往后读，消息读完不会被删掉，保留期内可以反复重放。系统设计里只要出现“把事件可靠地交给多个下游”“削峰”“事后重算”，Kafka 基本都是第一候选。
- 第 29 章关键技术：RedisRedis 是一个把数据全部放在内存里的数据结构服务器。它不只是键值缓存：字符串、哈希、列表、集合、有序集合、流、地理位置都是内置类型，每条命令在服务端原子执行。系统设计里，缓存、计数器、排行榜、限流、分布式锁、在线状态，几乎都会想到它。
- 第 30 章关键技术：PostgreSQLPostgreSQL 是系统设计面试里最稳妥的默认数据库：ACID 事务、约束、JOIN、各种索引都很成熟，单机能扛的量比很多人以为的大。除非题目给出明确理由（写入量远超单主、访问模式极简单、需要全文相关性排序），先选它，再说清楚什么时候要换。
- 第 31 章关键技术：DynamoDB 与 CassandraDynamoDB 和 Cassandra 都是按分区键水平扩展的键值 / 宽列存储：写入量几乎可以随节点线性增长，代价是放弃 JOIN 和灵活查询，表结构要围绕“会怎么读”来设计。两者放在一章讲，因为面试里的取舍几乎一样；区别在于一个是托管服务，一个是自己运维的无主集群。
- 第 32 章关键技术：ElasticsearchElasticsearch 是建立在 Lucene 之上的分布式搜索引擎。它的核心是倒排索引：先把文本切成词，再记录每个词出现在哪些文档里，所以“包含这些词、按相关性排序”的查询很快。系统设计里一旦出现全文搜索、多条件筛选加排序、日志检索，基本都会把它放在主数据库旁边，作为一份可以重建的搜索副本。
- 第 33 章关键技术：ZooKeeper 与 etcdZooKeeper 和 etcd 是给“协调”用的强一致存储：数据量很小，但每次写入都经过共识协议，所有节点对顺序达成一致。选主、分布式锁、服务发现、集群配置这类“全集群必须对同一件事看法一致”的问题，最后往往落到它们身上。它们不是用来存业务数据的。
- 第 34 章关键技术：Flink 与流处理流处理引擎（以 Flink 为代表）持续地读取事件流，在内存或本地磁盘里维护状态，边到边算，把结果写到下游。和“每条消息一个消费者处理”相比，它多了三样东西：按 key 分布的大状态、基于事件时间的窗口，以及故障后状态不丢、不重复计算的检查点机制。实时计数、Top-K、实时特征、风控规则，常常需要…
- 第 35 章关键技术：对象存储（S3）对象存储（Amazon S3、Google Cloud Storage、Azure Blob Storage）用来放文件：图片、视频、备份、日志、模型和数据集。它便宜、几乎无限扩容、极其持久，但只支持整对象的读写，不能在中间修改，也不适合当数据库用。系统设计里的规矩很简单：大文件进对象存储，数据库…
通用设计模式（选读）
- 第 36 章设计模式：实时更新很多产品需要服务器主动把变化推给客户端：新消息、司机的位置、抢票队列的进度、文档里别人的光标。HTTP 默认是客户端问、服务器答，所以“实时更新”其实包含两个问题：最后一公里怎么把数据送到客户端，以及服务端内部怎么把一个事件送到持有那个用户连接的那台服务器。
- 第 37 章设计模式：资源争抢当很多请求同时争抢同一份有限的资源（最后几张票、一个司机、一件爆款库存、同一个账户余额），“先读再写”的朴素做法就会出错：两个请求都读到“还剩 1 个”，都以为自己抢到了。这一章按从简单到复杂的顺序整理处理争抢的手段，以及它们分别在什么规模下失效。
- 第 38 章设计模式：多步骤流程下单这件事背后往往是好几步：占库存、扣款、生成订单、发通知，分别属于不同的服务和数据库。任何一步都可能失败、超时或者重复执行，而跨服务又没有一个能回滚一切的数据库事务。这一章讲怎样让这类流程“要么走完，要么干净地撤回”，并且在重试时不出错。
- 第 39 章设计模式：长时间运行的任务视频转码要几分钟，生成一份年度报表要十几分钟，爬一个网站要几个小时。这类工作不能塞进一次 HTTP 请求里：请求会超时，用户会刷新重试，服务器的连接和线程被长时间占住。通用的做法是异步任务：接口立即接下任务、返回一个任务 id，由后台的 worker 慢慢做，结果通过查询或通知交给用户。
- 第 40 章设计模式：大文件处理照片、视频、附件、数据集这类大文件，如果走“客户端 → 应用服务器 → 存储”的老路，应用服务器的带宽、内存和连接会被一点点耗尽，一次网络抖动就要从头再传。这一章讲大文件上传、下载和后处理的标准做法：让字节直接在客户端和对象存储之间流动，应用服务器只负责授权和记账。
- 第 41 章设计模式：扩展读大多数产品读远多于写：一条短链接被点击上万次，一条帖子被几百万人看到，一个演出页面在开票前被反复刷新。读多写少的系统，扩展的思路是一层层地把读请求挡在数据库之前，并且让剩下的读尽量便宜。顺序很重要：先做便宜的，再做复杂的。
- 第 42 章设计模式：扩展写读可以靠缓存和副本层层挡住，写却不行：每一次写都必须真正落到存储上，而且通常只有一个地方能接收它（主库、分区的 leader）。位置上报、聊天消息、点击日志、计数器这类写多的系统，扩展的办法是把写分散开、攒起来、或者换一种更擅长写的存储。
LLD 案例库（选读）
- 第 43 章LLD 案例：ATM 取款机ATM 这道题看起来简单：插卡、输密码、取钱。面试官真正想看的是两件事：一是你能不能把“当前处于哪个阶段”建模清楚，二是钱这件事上你有没有一致性意识——账户扣了款，钞票却没吐出来，这是绝对不能接受的。
- 第 44 章LLD 案例：自动售货机自动售货机常和 ATM 放在一起考，二者都要处理“状态”和“找零”。区别在于售货机自己保管钱：顾客投进来的硬币放在哪里，取消时退什么，卖出去之后怎么找零，这些都要在设计里说清楚。
- 第 45 章LLD 案例：国际象棋国际象棋是规则最多的 LLD 题之一。面试官不指望你把每条规则都写完，而是看你怎么组织规则：每种棋子各自怎么走，“走完不能让自己的王被将”这类全局规则放在哪，悔棋需要记住什么。
- 第 46 章LLD 案例：图书馆管理系统图书馆管理系统考的是建模：哪些是“书”，哪些是“书架上那一本”，借阅和预约分别挂在谁身上。模型一旦理顺，借书、还书、预约排队、罚款这些流程写起来都很直接。
- 第 47 章LLD 案例：酒店预订酒店预订的难点在“日期”这个维度：一间房不是简单的“空”或“满”，而是每一晚各自空或满。把库存按“房型 × 晚”来记，很多问题会简单得多：防超订、入住时分房、占房超时释放都建立在这个模型上。
- 第 48 章LLD 案例：Splitwise 分账Splitwise（多人记账分摊）这道题的代码量不大，考点集中在钱算得对不对：怎么分才能一分不差，余额怎么算，几个人互相欠钱时怎么用最少的转账结清。
- 第 49 章LLD 案例：电影院选座购票电影选座和系统设计里的订票系统是同一个问题的两种问法。这一章停在类和代码层面：座位状态挂在哪，多个座位怎么“要么全占、要么全不占”，占座超时怎么释放。
- 第 50 章LLD 案例：自提快递柜自提快递柜（Amazon Locker 这类）是一道小而完整的题：格口分配是一个简单的匹配问题，取件码涉及安全，过期处理涉及定时任务。题目不大，正好用来展示你对细节的把握。
- 第 51 章LLD 案例：外卖订单外卖平台的系统设计题考的是规模；放到 LLD 里，考点变成订单的生命周期：一个订单从下单到送达要经过哪些状态，谁可以推动哪一步，每一步触发什么动作。把这条状态机写清楚，餐厅、骑手、顾客三方的交互就都有了着落。
- 第 52 章LLD 案例：日志框架日志框架是一道“看起来人人都用过”的题，考的是你有没有想过它内部的取舍：级别怎么继承，一条日志怎么分发到多个目的地，写日志会不会拖慢业务线程，日志关掉时还有没有开销。
API 设计（选读）
- 第 53 章API 设计 1：REST、RPC 与 GraphQL设计 API 时，第一个问题往往是风格：REST、RPC（以 gRPC 为代表）还是 GraphQL。这三种没有谁绝对更好。选择取决于谁来调用、要不要缓存、需不需要流式传输、客户端的数据需求有多分散。这一章先讲三者的核心差别，再用一个聊天应用说明它们怎么搭配使用。
- 第 54 章API 设计 2：分页与幂等分页和幂等是 API 设计里最常被追问的两个细节，而且都和“请求会被重复执行”有关：翻页时数据在变化，重试时同一个请求被执行两次。这一章用一个支付 API 做案例：列出账户的支付记录，以及创建一笔支付。
- 第 55 章API 设计 3：版本演进与错误设计API 一旦对外发布，就有你看不到的客户端依赖它：别人的手机 App、合作方的服务器脚本、三年前写完就没人维护的集成。这一章讲两件事：怎么修改 API 而不把这些客户端弄坏，以及出错时怎么告诉调用方发生了什么。案例是一个电商的订单 API。
- 第 56 章API 设计 4：认证授权与限流开放给第三方开发者的 API，要回答两个问题：你是谁、你能做什么（认证和授权），以及你能调用多少（限流和配额）。案例是一个天气开放平台：开发者注册项目拿到 API Key 查询天气预报；另外，用户可以授权第三方 App 读取自己在平台上收藏的地点。
- 第 57 章API 设计 5：Webhook 与长任务有些操作没法在一次请求里做完：上传一个 2GB 的视频，转码要几分钟，生成一份年度报表要半小时。这一章讲三件事：大文件怎么传，长任务的接口怎么设计，任务完成后怎么通知调用方。案例是一个视频平台的上传和转码 API。