系统设计解题框架

先看清问题

系统设计面试里常见的失败并不是答不出某个组件，而是在题面还很含糊时就开始画图。需求规模没问清，QPS、存储和带宽全凭感觉；等到面试官追问“为什么选这个”，才发现自己只是在背一套看似标准的架构。实际做架构也有类似困境：方案图画得漂亮，热点 Key、单点依赖和一致性取舍却被放在后面，一旦上线就被真实流量推翻。

技能如何工作

这个技能把系统设计拆成一条可复述的路径：澄清 → 估算 → 草图 → 深入 → 权衡。它不会替你指定某个固定架构，而是强制先确认规模、约束和优化重点，再动笔设计。

• 先澄清后设计：把用户规模、请求特征和边界条件问清楚，避免方向跑偏。
• 做量级估算：用“用户数 × 行为频率”推 QPS、存储和带宽，让后续选型有依据。
• 先画主干再补异常：先画核心组件与数据流，之后才处理缓存、队列、限流等扩展点。
• 深入一个难点：从一致性、热点、可用性里挑出最关键的问题讲透，而不是所有点都浅尝。
• 讲清权衡：每个技术选型都说明为什么不选另一个方案，这才是系统设计真正被考察的地方。

它适合面试前练“从零设计 XX 系统”，也适合在日常架构评审中补上容量估算和取舍说明的缺口。触发场景包括 system design、架构面试、分布式设计、高可用设计和技术选型。

适用边界

它提供的是思考框架，不是万能答案库。真实系统仍要回到具体业务约束、团队运维能力和官方最佳实践；容量估算也应结合线上观测修正。不要把模板当成架构结论，更不要因为追求流程完整而忽略最关键的性能瓶颈。