系统设计题通用答题框架
问题
面对“设计一个某某系统”的开放式题目，应该如何澄清需求、拆分架构、识别关键风险，并在有限的面试时间内给出有层次、可落地的方案？
系统设计没有唯一答案，面试官主要观察的是分析过程和技术取舍。可以按八步回答：
- 澄清目标与边界：用户是谁、核心链路是什么、哪些功能不做；
- 明确规模与指标：并发、数据量、延迟、可用性、端与浏览器范围；
- 定义领域模型：核心实体、状态、唯一标识和生命周期；
- 画总体架构：客户端、接入层、服务层、存储、异步任务与第三方依赖；
- 深入关键链路：优先讲最难、最能体现岗位价值的两三个问题；
- 补齐非功能设计：性能、容错、安全、可观测性、兼容性；
- 说明演进与取舍：MVP 怎么做，规模扩大后如何演进；
- 总结风险与验证：最大风险是什么，如何用 PoC 和指标验证。
不要一上来报技术名词。先回答“为什么这样设计”，再回答“用什么实现”。
一、系统设计题到底在考什么
系统设计题通常不要求在白板上还原一套真实生产系统，而是考察候选人能否：
- 把模糊需求转换成明确的工程约束；
- 找出真正决定架构的关键矛盾；
- 在一致性、可用性、成本、体验和交付周期之间做取舍；
- 识别前端、服务端和基础设施的责任边界；
- 设计可以验证、监控、降级和逐步演进的系统。
系统设计题不是“组件越多越高级”。如果日活只有几千，直接引入复杂的分布式架构反而说明缺少成本意识。架构复杂度必须由明确的业务约束驱动。
二、八步答题流程
1. 澄清目标与边界
至少确认以下问题：
| 维度 | 应该追问什么 | 设计影响 |
|---|---|---|
| 用户 | 面向公众、内部员工还是开发者 | 权限、兼容性、交互复杂度 |
| 核心链路 | 最重要的一到两条用户路径是什么 | 决定优先深入的模块 |
| 协作模式 | 单人、多端还是多人实时协作 | 是否需要同步协议和冲突解决 |
| 数据特征 | 文本、图片、音视频还是结构化数据 | 存储、传输与渲染方案 |
| 实时性 | 秒级、分钟级还是离线可接受 | SSE、WebSocket、轮询或批处理 |
| 边界 | 本题明确不设计什么 | 控制讨论范围 |
可以主动声明合理假设，例如：“我先按千万级用户、峰值十万在线、核心链路要求 99.9% 可用来设计；如果规模不同，我会调整缓存和服务拆分。”
2. 明确规模和质量目标
不必追求精确数字，但要说明数字如何影响方案：
- 峰值并发、读写比例、单条数据大小；
- 首屏、交互和接口的延迟目标；
- 可用性、恢复时间目标（RTO）与数据恢复点目标（RPO）；
- 支持的终端、浏览器和网络条件；
- 隐私、合规、无障碍与审计要求。
3. 定义领域模型与状态
先定义实体和状态，再讨论存储。以在线文档为例：
Document：文档元数据和当前版本；Operation：一次可同步、可重放的编辑操作；Member：成员、角色和权限范围；Snapshot：用于恢复和加速加载的快照；Presence：光标、选区和在线状态等临时信息。
重点回答：谁拥有数据、ID 如何生成、状态怎样流转、哪些数据必须持久化、哪些可以丢弃。
4. 给出总体架构
总体图要表达数据从哪里来、经过什么边界、失败时停在哪里，而不只是罗列技术组件。
5. 深入关键链路
选择两到三个最能决定架构的问题展开：
- 大数据量：分页、虚拟化、增量计算、Worker；
- 实时协作：连接管理、顺序、幂等、冲突解决；
- 富交互：状态建模、撤销重做、插件机制；
- 多端离线：本地数据库、变更日志、同步协议；
- 平台型产品：Schema、扩展点、版本兼容和租户隔离。
优先讲“数据正确性和失败恢复”，再讲性能优化。一个很快但会丢数据或产生错误状态的系统不是合格设计。
6. 补齐非功能设计
| 能力 | 关键问题 |
|---|---|
| 性能 | 首屏、交互、长任务、缓存、分包、虚拟化 |
| 可用性 | 超时、重试、幂等、熔断、降级、回滚 |
| 安全 | 认证、授权、输入校验、资源隔离、审计 |
| 可观测性 | 日志、指标、Trace、版本号、用户会话关联 |
| 兼容性 | 浏览器能力检测、渐进增强、降级路径 |
| 可维护性 | 模块边界、契约、测试、文档和负责人 |
7. 描述 MVP 与演进路线
推荐给出分阶段设计：
- MVP：单体服务、成熟托管能力、满足核心链路；
- 增长期：读写分离、缓存、异步化、热点治理；
- 规模化：按领域拆服务、跨地域容灾、平台化治理。
同时说明每次升级的触发指标，例如连接数、P95 延迟、错误率或发布冲突次数，而不是为了“先进”提前拆分。
8. 总结风险和验证方式
收尾时主动指出：
- 目前最大的不确定性是什么；
- 哪个假设需要 PoC、压测或用户研究验证；
- 上线后看哪些成功指标和护栏指标；
- 出问题如何止血、回滚和恢复数据。
三、前端系统设计的五个纵向切面
前端系统设计不能只画后端服务，应至少覆盖以下切面：
- 渲染切面：CSR、SSR、流式渲染、Canvas、虚拟列表；
- 状态切面：服务端状态、客户端状态、表单状态、URL 状态；
- 数据切面：缓存、同步、版本、失效、离线和冲突；
- 扩展切面：插件、Schema、事件、SDK、兼容策略；
- 治理切面：监控、灰度、权限、安全、测试与回滚。
四、20 分钟时间分配
| 时间 | 内容 |
|---|---|
| 0～3 分钟 | 澄清需求、用户和规模 |
| 3～6 分钟 | 定义领域模型和核心接口 |
| 6～10 分钟 | 画总体架构与主数据流 |
| 10～16 分钟 | 深入两个关键难点 |
| 16～19 分钟 | 性能、安全、容错和可观测性 |
| 19～20 分钟 | 总结取舍、风险与演进 |
五、可直接复用的回答模板
1. 目标：服务谁，解决什么问题，核心成功指标是什么？
2. 边界：本次设计包含什么、不包含什么？
3. 规模：并发、数据量、延迟、可用性和端侧约束是什么？
4. 模型：核心实体、状态机、ID 与版本如何设计？
5. 架构：客户端、网关、服务、存储和异步任务怎样协作？
6. 难点：选择两个决定性问题深入讲清数据流和失败路径。
7. 保障：性能、安全、容错、监控、测试和发布怎样做？
8. 演进：MVP 如何落地，什么时候升级架构？
9. 总结：最大取舍、风险和验证方式是什么？
常见面试问题
Q1: 系统设计题没有数据规模时怎么办？
答案：主动询问；如果面试官让你自行假设，就声明一个合理量级，并说明方案对量级变化的敏感点。关键不是猜中数字，而是证明你知道规模会影响哪些决策。
Q2: 是否必须做容量估算？
答案：前端岗位不一定需要精确计算服务器数量，但至少要估算用户量、并发连接、单次载荷和本地数据规模。它们直接决定分页、虚拟化、WebSocket 连接、缓存和存储策略。
Q3: 系统设计时应该先画图还是先讲需求？
答案：先讲需求和假设。没有边界的架构图无法判断对错，也很容易在错误的问题上过度设计。
Q4: 如何体现架构设计中的技术深度？
答案：选择最关键的一两个链路，讲清状态、时序、失败模式、数据一致性和取舍。把每个模块都浅讲一遍，通常不如把核心难点讲透。
Q5: 如何判断是否过度设计？
答案：检查每一层复杂度是否都对应明确的业务约束或可观测的触发指标。如果删掉某组件仍能满足当前目标，而且没有清晰的近期演进信号，就应优先选择简单方案。