第 1 章：系统设计面试框架

系统设计面试通常 45–60 分钟，题目往往只有一句话：“设计一个短链接服务”“设计 Twitter 首页 Feed”。这类题没有标准答案。面试官主要看三件事：你能不能把模糊的问题拆清楚，能不能在约束下做出合理取舍，能不能边做边把思路讲明白。

框架不是用来背的模板，它的作用是让你不漏掉关键环节，并且把时间花在最能拿分的地方。本章介绍一套五步流程，以及贯穿全程的估算方法和不同职级的评价差异。

总览：五步与时间分配

以 45 分钟为例（去掉开场寒暄和结尾提问，实际可用约 35–40 分钟）：

flowchart LR
  accTitle: 答题框架：五个步骤与非功能需求
  req["需求"] --> ent["实体"] --> api["API"] --> hld["高层设计"] --> deep["深挖"]
  req --> nfr["非功能需求"]
  nfr --> hld
  nfr -->|"决定深挖往哪个方向走"| deep

第 1 步：需求澄清

功能需求用“用户可以……”的句式写，只保留 3–5 条核心功能。以 Twitter Feed 为例：

• 用户可以发推文（文字 + 图片）
• 用户可以关注其他用户
• 用户可以查看关注对象的推文，按时间倒序排列

同时明确说出不做什么（out of scope），比如“私信、广告、搜索先不考虑”。这样既省时间，也能让面试官看到你有范围意识。

非功能需求要量化，而且要和这道题相关：

• 规模：DAU 多少？读写比多少？（Feed 类系统通常读远多于写）
• 延迟：写成“Feed 加载 p99 < 300ms”，而不是“要快”
• 可用性与一致性：发推后几秒内别人能看到即可，说明可以接受最终一致
• 持久性：已发布的推文不能丢

常见误区：

• 问一长串与设计无关的问题，10 分钟就过去了。
• 面试官说“你来定”时犹豫不决。正确做法是直接给出合理假设并说出来：“我假设 2 亿 DAU，读写比约 100:1。”

第 2 步：核心实体

列出系统中的主要对象即可，例如 User、Tweet、Follow、Media。这一步不需要写完整表结构，字段可以在高层设计时按需补充。它的作用是和面试官对齐用词，同时为 API 设计打基础。

第 3 步：API 设计

默认用 REST；需要服务端主动推送时考虑 WebSocket 或 SSE；内部服务之间可以提 gRPC。

POST /v1/tweets               body: { text, media_ids }  → { tweet_id }
POST /v1/users/{id}/follow
GET  /v1/feed?cursor=xxx&limit=20                        → { items, next_cursor }

几个加分细节：

• 当前用户的身份从认证 token 中获取（请求头里的 JWT 或 session），不要让客户端在请求体里自己填 user_id，否则任何人都能冒充别人。
• 列表接口用游标分页（cursor）。数据频繁插入时，offset 分页容易出现重复或遗漏，深翻页也更慢。
• 写接口考虑幂等，例如让客户端带一个 idempotency key，防止网络重试导致重复发帖。

第 4 步：高层设计

目标是先拿出一个能工作的方案：逐条走通功能需求的数据流，不要一开始就追求完美。

flowchart TD
  accTitle: Twitter Feed 的高层设计
  client["Client"] --> lb["LB / Gateway"]
  lb --> tweet["Tweet Service"]
  lb --> feed["Feed Service"]
  tweet --> tdb[("Tweet DB")]
  feed --> fcache[("Feed Cache")]
  tdb -.->|"异步"| fcache

讲解时沿着请求路径叙述：“用户发推 → 网关鉴权 → Tweet Service 写库 → 异步更新粉丝的 Feed 缓存……”。遇到需要优化的地方，先标注“这里稍后深挖”，保持节奏，别在这一步陷进细节。

第 5 步：深挖

深挖的方向由非功能需求决定：规模带来扩展问题，延迟要求带来缓存问题，可用性要求带来单点故障问题。每个深挖点可以按下面的结构展开：

1. 问题：例如“某个大 V 有 1 亿粉丝，写扩散（fan-out on write）一次就要写 1 亿条”
2. 方案：至少给两个选项，例如写扩散、读扩散、二者混合
3. 权衡：延迟、存储、实现复杂度、一致性
4. 决定：结合本题需求选一个，并说明理由

Senior 及以上的候选人应该主动提出深挖点，同时也要灵活跟随面试官感兴趣的方向。

粗略估算（Back-of-the-Envelope）

估算只有一个目的：支撑设计决策。如果算出来的数字不会改变你的方案，就一句话带过。

示例：2 亿 DAU，每人每天刷 20 次 Feed → 每天 40 亿次读 ≈ 4×10⁹ ÷ 10⁵ = 4 万 QPS（精确值约 4.6 万），峰值按 3 倍算约 12–14 万 QPS。结论：单个数据库扛不住，需要缓存加读副本。这就是用估算推动设计决策。

存储：每天新增 5,000 万条推文，每条约 1KB → 50GB/天 → 一年约 18TB（不含图片视频）。说明几年的数据单机放不下，需要考虑分片；媒体文件则应放到对象存储。

不同职级的期望

注意，Staff 不等于“用更多组件”。很多时候 Staff 级别的表现恰恰是说出：“这里一个 Postgres 就够了，原因是……”。

常见失分点

• 跳过需求直接画图，做到一半发现方向错了
• 堆砌名词：Kafka、Redis、Cassandra 全用上，却说不出为什么
• 深挖只给一个方案，没有任何权衡
• 时间失控：过了 20 分钟还在聊需求
• 长时间沉默：思考时也要把思路说出来，面试官没法给沉默打分