system-design-101 实战指南：用 7 步流程法从容应对系统设计面试

系统设计面试考察的不是背诵架构图，而是候选人在有限时间内、面对开放问题时如何有条不紊地澄清需求、估算规模、拆解组件并做出权衡。本文基于 system-design-101 仓库中 how-to-ace-system-design-interviews-like-a-boss 的核心方法论，系统讲解一套可复用的 7 步面试流程：从需求澄清到可靠性设计，每一步都给出具体的提问方向、可交付物与注意事项，并同步串联仓库内数十篇配套指南，帮助你从"会画图"进阶到"能讲清每个设计决策背后的为什么"。读完本文，你将拥有一份可以直接用于模拟面试的完整检查清单，以及一套查漏补缺的复习路线图。

为什么需要一套固定的面试流程

系统设计面试的问题通常高度开放（例如"设计一个像 Twitter 这样的系统"），没有唯一正确答案。评审者真正观察的是三件事：

1. 你能否系统化地推进，而不是上来就画架构图；
2. 你能否识别出关键的规模与约束条件；
3. 你能否在多个候选方案之间做出有理有据的权衡。

仓库中的 system-design-blueprint-the-ultimate-guide 提到，一个可复用的蓝图/模板应该覆盖负载均衡、API 网关、通信协议、CDN、数据库、缓存、消息队列、唯一 ID 生成、可扩展性、可用性、性能、安全、容错与弹性等讨论点。下文这套 7 步流程正是把上述讨论点组织成一个有顺序、有节奏的回答框架。

第 1 步：需求澄清（Requirements Clarification）

这是整个面试中最容易拉开差距的一步。面试官给出题目后，先不要急着画图，而是通过提问把问题的边界定下来。具体要澄清两类需求：

• 功能需求（Functional Requirements）：系统最核心的功能是什么？哪些功能是 MVP 必须包含的，哪些可以放到二期？例如设计一个聊天系统，是点对点消息还是群聊？是否要求已读回执、在线状态、多媒体消息？
• 非功能需求（Non-Functional Requirements）：数据量级（日活用户、单用户日均请求）、可用性目标（多少个 9）、延迟目标（p99 延迟）、一致性要求（强一致还是最终一致）等。

提问要有目的性，一次问清几个关键问题即可，不要无限发散。仓库中的 a-cheat-sheet-for-system-designs 列出了设计系统时值得过一遍的 15 个核心概念，其中"需求收集（Requirement gathering）"排在第一位，随后才是系统架构、数据设计、领域设计等，可见需求澄清是整个设计的起点。若题目涉及数据库选型，也可以提前参考 how-do-you-decide-which-type-of-database-to-use 里的决策思路，把"读多写多、数据模型、一致性要求"等问题纳入澄清清单。

第 2 步：容量估算（Capacity Estimation）

需求澄清之后，用量化数字把"规模感"建立起来，这决定了后续所有组件选型。估算维度包括：

• 用户与流量：日活用户数（DAU）、平均每秒查询数（QPS）、峰值 QPS 与平均 QPS 的比值；
• 存储与内存：单条数据大小 × 总量 = 存储需求；热数据占比 × 总量 = 缓存内存需求；
• 计算与网络：CPU 密集型还是 IO 密集型、带宽需求、是否需要 CDN 缓解网络压力。

估算不需要精确到个位数，量级正确即可——从百万级到十亿级的差异才真正影响架构选型。关于吞吐与规模的度量口径，可参考 system-design-cheat-sheet：QPS（每秒查询数）和 TPS（每秒事务数）是衡量吞吐的常用指标，而可用性通常用"3 个 9""4 个 9"描述，例如 99.99% 的可用性意味着每天只能停机 8.64 秒。做容量估算时，把这些数字挂在嘴边，会让面试官确信你清楚系统要服务多大规模。

第 3 步：高层设计（High-Level Design）

容量心中有数后，把系统拆解为若干核心组件，画出第一版块图。典型组件包括：

• 客户端应用：Web / 移动端，决定通信协议与推送方式；
• 服务器层：应用服务、无状态化设计；
• 负载均衡器：将流量分发到多台实例，避免单点成为瓶颈；
• 数据库层：主库、从库、缓存；
• 外部服务：对象存储、消息队列、CDN 等。

关键技巧是先画一个简单的方块图，标出组件之间的连线，并把注意力放在数据流上——请求从哪里进来、经过哪些处理、数据落在哪里、如何返回。不要一开始就追求完整细节。仓库中的 must-know-system-design-building-blocks 把常用组件归纳为 6 大类，正好可以作为画图的组件清单：

• 分布式计算：分布式消息队列（解耦服务）、分布式缓存（内存加速）、分布式任务调度器；
• 可扩展性与性能：服务伸缩、CDN（就近分发内容）、一致性哈希（节点增减时最小化键重映射）；
• 服务管理：服务发现（避免硬编码网络地址）；
• 网络与通信：DNS、负载均衡器、API 网关（微服务的统一入口）；
• 数据存储与管理：数据库、对象存储（图片/视频/文档）、分片（水平分区）、复制（副本扩展读能力）；
• 可观测性与弹性：通过指标（metrics）、日志（logging）和链路追踪（tracing）洞察系统内部状态。

第 4 步：数据库设计（Database Design）

高层设计定下数据流向之后，进入数据层设计，分三步走：

1. 数据建模：梳理实体、关系与访问模式。是强关系型（如订单与用户）还是文档型（如用户资料）？主要查询模式是什么？
2. 选型：根据数据模型与访问模式选择数据库类型。SQL 适合强一致、多表关联；NoSQL（文档、键值、宽列、时序、图）各自适配不同的访问模式，可对照仓库中的 types-of-databases 与 understanding-database-types 系统梳理各类数据库的适用场景。
3. Schema 设计：确定表结构/文档结构、主键与外键、索引策略。可以结合 8-data-structures-that-power-your-databases 理解 B+ 树、LSM 树、跳表等底层结构如何决定读写性能，从而解释为什么某些 schema 设计在特定数据库上更快。

选型之后，还要在设计中预留扩展路径：是走垂直方向（加 CPU/内存/磁盘）还是水平方向（分区、分片）？两种路线的差异可参考 vertical-partitioning-vs-horizontal-partitioning，而 7-must-know-strategies-to-scale-your-database 则提供了读副本、分片、去规范化等具体手段。

第 5 步：接口设计（Interface Design）

数据库就位后，定义系统对外的"边界"——组件之间如何交换数据。这一步要明确两件事：

• API 端点：面向客户端与面向内部服务的接口分别是什么？例如消息系统的 POST /messages、GET /messages/{id}，以及推送服务与消息存储之间的内部接口；
• 事件模型：如果采用事件驱动架构，需要定义事件类型、事件结构、投递语义（at-most-once / at-least-once / exactly-once），可参考仓库中的 delivery-semantics。

同时要选定组件间的通信方式。候选方案包括：

• REST：基于 HTTP 的资源化接口，简单直观，适合大多数面向客户端的场景；
• GraphQL：由客户端声明所需字段，适合字段高度定制、多端复用的场景；
• gRPC：基于 HTTP/2 与 Protobuf 的高性能 RPC，适合服务间内部通信、低延迟场景；
• 事件驱动 / 消息队列：通过消息中间件异步解耦，适合削峰填谷、跨团队集成。

四种风格的取舍可对照 a-cheatsheet-on-comparing-api-architectural-styles，REST 与 GraphQL 的具体差异见 rest-api-vs-graphql，gRPC 的工作原理见 what-is-grpc。在面试中明确说出"我选择 gRPC 是因为服务间低延迟、强类型"，比只罗列协议名称要更有说服力。

第 6 步：可扩展性与性能（Scalability and Performance）

这是系统设计面试的"重头戏"，需要针对系统的规模瓶颈主动给出方案。原方法论列出的候选技术包括：垂直扩展与水平扩展、缓存、索引、去规范化（denormalization）、分片（sharding）、复制（replication）、CDN。

仓库中的 8-must-know-scalability-strategies 把这方面的策略系统化为 8 条，非常适合作为面试时的"工具箱"：

• 无状态服务：服务不依赖特定服务器上的数据，天然易于水平扩展；
• 水平扩展：增加服务器数量分摊负载；
• 负载均衡：把请求均匀分发到多台服务器；
• 自动伸缩：按实时流量自动调整资源；
• 缓存：把热点数据放在内存中，减轻数据库压力；
• 数据库复制：多副本承载读请求，同时提升冗余；
• 数据库分片：数据分布到多个实例，同时扩展读写；
• 异步处理：把耗时任务移到后台 Worker，让新请求不被阻塞。

关于如何系统化地"找瓶颈"，a-crash-course-on-architectural-scalability 指出了三大扩展瓶颈：集中式组件（可能成为单点故障）、高延迟组件（执行耗时的操作）、紧耦合（组件难以独立扩展）；对应的原则是无状态、松耦合、异步处理。此外，缓存策略（top-5-caching-strategies）与一致性哈希（consistent-hashing）是扩展话题中两个高价值加分项，值得重点准备。

第 7 步：可靠性与弹性（Reliability and Resiliency）

最后一步是给设计"上保险"：找出系统中的单点故障（SPOF），并说明如何缓解其影响。这一步的产出通常包括冗余部署、故障转移（failover）、降级方案与监控告警。

仓库中的 a-cheat-sheet-for-designing-fault-tolerant-systems 给出了容错系统设计的 6 条核心原则，可以直接套用到面试答案中：

• 复制（Replication）：在多个节点/位置保存数据或服务的多份副本；
• 冗余（Redundancy）：准备可随时接管的备用组件；
• 负载均衡（Load Balancing）：流量分散到多台服务器，避免单台服务器成为故障点；
• 故障转移（Failover）：主组件失效时自动切换到备用组件；
• 优雅降级（Graceful Degradation）：部分组件失败时，系统以缩减的功能继续运行，而不是整体崩溃；
• 监控与告警（Monitoring and Alerting）：持续监控健康与性能，对异常及时告警。

可用性的具体实现层级可以借用 system-design-cheat-sheet 中介绍的四类冗余模式：热-热（hot-hot）（双实例同时处理相同输入，下游需去重）、热-温（hot-warm）（仅热侧输出，热侧故障时温侧接管）、单主集群（主实例复制到副本）、无主集群（写入复制到多实例，只要写入实例数 + 读取实例数 > 总实例数即可保证读到有效数据）。监控与告警的工程落地可参考 logging-tracing-metrics。可靠性话题更深入的可扩展阅读还包括 how-do-we-design-for-high-availability 与 top-eventual-consistency-patterns-you-must-know。

贯穿始终：系统设计的一切都是权衡

7 步流程走完并不代表回答结束——优秀的候选人还会主动总结自己在关键节点上做的取舍。仓库中的 top-5-trade-offs-in-system-designs 明确说："Everything is a trade-off. Everything is a compromise. There is no right or wrong design."（一切都是权衡，没有绝对正确或错误的设计）。面试中最常被讨论的五组权衡是：

• 成本 vs. 性能：更高的性能往往意味着更大的缓存与更强的机器，预算有限时如何取舍；
• 可靠性 vs. 可扩展性：更多副本更可靠，但也更贵、更难扩展；
• 性能 vs. 一致性：强一致拖慢写入，最终一致提升吞吐但带来短暂读旧数据；
• 安全 vs. 灵活性：严格的安全策略会限制架构的灵活演进；
• 开发速度 vs. 质量：MVP 快速上线与长期可维护性之间的平衡。

围绕这五组权衡，8-common-system-design-problems-and-solutions 还给出了一套"问题-解法"速查表（读多系统用缓存、高写入用异步 Worker 与 LSM 树数据库、单点故障用冗余与故障转移、高可用用负载均衡与复制、高延迟用 CDN、大文件用块存储与对象存储、监控用集中式日志如 ELK、慢查询用索引与分片），很适合在模拟面试后用来做"这个系统我漏了哪些典型解法"的自查。

如何把 7 步流程变成日常训练

流程只有反复演练才能内化。建议按以下方式使用本仓库配套资源：

1. 先跑流程，再对答案：找一道经典题目（如设计一个 URL 短链、聊天系统或新闻 Feed），严格按 7 步流程计时演练；练完再对照 system-design-cheat-sheet、a-cheat-sheet-for-system-designs 和 8-common-system-design-problems-and-solutions 检查遗漏。
2. 按步骤补课：哪一步薄弱就钻哪一步——容量估算不熟练就看 a-crash-course-on-architectural-scalability；数据库选型没把握就补 how-to-choose-the-right-database；接口设计没思路就看 a-cheatsheet-on-comparing-api-architectural-styles。
3. 以真实案例收尾：演练到一定程度后，阅读仓库中的大型系统案例（如 reddit's-core-architecture、design-gmail、design-google-maps），观察真实系统如何落地这 7 步，并复述它们的取舍理由。

把以上 7 步流程（澄清需求 → 估算容量 → 高层设计 → 数据库设计 → 接口设计 → 可扩展性与性能 → 可靠性与弹性）当作面试回答的"主干道"，再配合仓库里的速查表与真实案例作为"服务区"，你就能在系统设计轮中始终保持思路清晰、节奏可控，并让每一个架构决策都显得有依据、可辩护。