system-design-interview

系统设计面试技能

构建一份完整、符合面试要求的系统设计方案，涵盖澄清问题、需求、容量估算、架构、组件设计和权衡取舍。同样适用于实际架构讨论。

必要输入

如果用户未提供，请询问以下内容：

• 要设计的系统（例如：“设计一个 URL 缩短服务”“设计一个通知服务”“设计 Twitter 的信息流”）
• 范围（面试准备／实际架构决策／模拟练习）
• 规模目标（大致数值：DAU、每秒请求数、数据量，或“假设为典型 Web 规模”）
• 约束或优先级（例如：优先保证可用性而非一致性、尽量降低成本、低延迟读取）
• 可用时间（仅适用于面试场景：30／45／60 分钟；实际架构讨论可跳过）
• 重点（可选——希望深入探讨的领域，例如“重点关注数据库设计”或“多花些时间讨论扩展”）

输出格式

1. 澄清问题

开始设计前，列出 4–6 个会影响设计的问题。例如：

• 读多还是写多？（影响缓存和数据库选型）
• 面向全球还是单一区域？（影响延迟要求）
• 强一致性还是最终一致性？（影响存储和复制）
• 可接受的延迟目标是什么？（p50／p99）
• 是否有现有基础设施方面的约束？

如果是在回答面试题，接着说明假设并继续作答。

2. 功能需求

核心功能（必须具备）：

• [功能 1]
• [功能 2]
• [功能 3]

不在本设计范围内的内容：

• [有意排除的内容及原因]

3. 非功能需求

需求	目标
可用性	[例如：99.9%／99.99%]
延迟	[例如：读取的 p95 < 100ms]
吞吐量	[例如：峰值 10k 次写入／秒]
一致性	[强一致性／最终一致性]
持久性	[例如：99.999%——不丢失数据]

4. 容量估算

流量：

• DAU：[X]
• 读取／秒：[X]（峰值：[X]）
• 写入／秒：[X]（峰值：[X]）

存储：

• 单条记录大小：[X 字节]
• 每日记录数：[X]
• 5 年存储量：[X GB/TB]

带宽：

• 入站：[X MB/s]
• 出站：[X MB/s]

5. 高层架构

绘制一张针对该系统的 ASCII 图。除非确实适用，否则不要默认采用客户端→CDN→LB→API→缓存→数据库的模板。为每个组件标注所选的具体技术（例如“K​​afka”而非“消息队列”，“PostgreSQL”而非“数据库”）。用 1–2 句话描述每个组件的职责，以及选择该技术的原因。

6. 组件深入分析

选择 2–3 个最关键或最有意思的组件，深入分析：

[组件 1：例如，数据库层]

• 选型：[技术及原因——例如：PostgreSQL 可提供 ACID 保证，Cassandra 写入吞吐量高]
• Schema 设计（高层）：[关键表／集合及其结构]
• 索引策略：[为哪些内容创建索引及原因]
• 复制：[主从／多主——以及原因]

[组件 2：例如，缓存策略]

• 缓存类型：[Redis／Memcached——以及原因]
• 缓存内容：[热点数据——例如：用户会话、频繁读取的数据]
• 缓存失效：[TTL／写穿／写回——权衡取舍]
• 缓存命中率目标：[例如：95%]

[组件 3：例如，API 设计]

• 关键端点：[列出最重要的 3–5 个 API 调用]
• 身份验证：[JWT／OAuth／API 密钥]
• 限流：[限流位置和速率]

7. 数据流

端到端梳理两条最关键的路径：

写入路径：[步骤 1 → 步骤 2 → 步骤 3……] 读取路径：[步骤 1 → 步骤 2 → 步骤 3……]

8. 扩展瓶颈及缓解措施

瓶颈	缓解措施
[例如：数据库写入吞吐量]	[例如：按 user_id 分片、批量写入]
[例如：热点键缓存未命中]	[例如：进程内本地缓存、概率性提前过期]
[例如：单一区域延迟]	[例如：多区域部署、GeoDNS 路由]

9. 权衡与替代方案

明确说明选择了什么，以及为此舍弃了什么：

决策	原因	权衡
[例如：最终一致性]	[可用性更高、延迟更低]	[可能读取到过时数据]
[例如：选择 SQL 而非 NoSQL]	[支持复杂查询和 ACID 事务]	[水平分片更困难]
[例如：通过队列进行异步处理]	[解耦性更好、更具韧性]	[交付具有最终性，调试更困难]

10. 后续考量

生产环境中需要处理、但不在本次设计讨论范围内的事项：

• 监控与告警（哪些指标很重要）
• 灾难恢复与备份策略
• 安全（身份验证、静态和传输加密、速率限制）
• 规模扩大后的成本优化
• 渐进式发布与功能标记

质量检查

• 澄清问题会影响设计（不是泛泛而谈的填充内容）
• 容量估算展示计算过程：DAU → 每日请求数 → 每秒请求数 → 每条记录的存储空间 → 总存储量，以便核验数字是否合理
• 权衡表中的每一行都填写了权衡项（没有空白或写着“无”的行）
• 至少深入分析 2 个组件，并说明技术选择的理由
• 权衡部分坦诚客观（不只是阐述所选方案的优点）
• 端到端描述关键路径的数据流

反模式

• 不要在澄清需求前就直接提出解决方案——始终先明确功能性和非功能性需求
• 不要在未讨论权衡的情况下给出设计——每项架构决策都有必须说明的成本与收益
• 不要使用含糊的容量估算——展示实际计算（QPS、存储字节数、带宽），而不只是说“可以支持大规模”
• 不要默认按无限规模设计——根据已说明的需求匹配设计
• 不要跳过数据模型——缺少实体定义和数据流的系统设计并不完整

使用示例

• “帮我回答一道系统设计面试题：[问题]”
• “为系统设计面试设计 [系统]”
• “如何为 [系统] 设计可扩展的架构？”
• “我有一场系统设计面试——题目是 [X]”
• “设计一个 [URL 缩短器 / 聊天系统 / 通知服务 / 信息流]”