System Design Interview Framework
System Design Interview Framework（系统设计面试框架） 是一种结构化的架构设计讨论模板。系统设计面试本质上是一场开放式的“技术合议”，旨在考查求职者在面临模糊、复杂的业务需求时，理清需求假设、设计基本可行解、权衡方案优劣（Trade-offs）并与面试官进行技术协作的综合工程能力。
Source: 2026-06-29-youtube-youtu-be-1Ut6RouSs0w-si-PmgouLaO2ACEXgXv（来源未公开） (Note: Detailed system design mapping from Terry Chen's interview tips)
系统设计面试核心步骤
graph TD A["① 需求与容量厘清 (Clarify Requirements)"] --> B["② 系统容量估算 (Scale Estimations)"] B --> C["③ 接口与数据定义 (API & Schema Design)"] C --> D["④ 基础可行方案 (Working Solution/High-Level)"] D --> E["⑤ 深度拓展与瓶颈分析 (Deep Dive & Scale)"] E --> F["⑥ 方案利弊权衡 (Trade-offs & Iteration)"]
1. 需求厘清 (Clarify Requirements)
- 主动提问，缩小 Scope：面试官给出的题目通常极度笼统（如“设计 Twitter 平台”）。求职者不可自行默许假设，应通过提问将其约束为具体可实现的最小功能子集（Functional Requirements，如发推文、用户关注、时间线刷新）。
- 设定技术指标：明确非功能性需求（Non-functional Requirements），如动态刷新延迟低于 300 毫秒、系统高可用性（Availability）与强一致性（Consistency）的权衡（CAP 定理）。
2. 系统容量估算 (Scale Estimations)
- 估算日活跃用户数（DAU）、日均发帖数、读取与写入比例（Read/Write Ratio）。
- 计算网络带宽（Bandwidth）、QPS（每秒请求数）、以及未来几年的数据库存储容量需求（Storage Estimates），以此作为架构选型（如是否需要分库分表、引入缓存层）的物理依据。
3. API 与 Schema 设计
- 编写清晰的 API Endpoint 定义（Request Params / Response JSON）。
- 设计底层数据实体与表结构（Data Schema），明确主外键及调用关联。
4. 建立可行基础解 (Working Solution)
- 一开始切忌直接抛出极其复杂的微服务或高并发冗余架构。面试官更在乎求职者能先搭建一个简单易懂的完整链路。
- 快速画出 High-Level 架构图（Client -> Load Balancer -> Web App Server -> DB），确保数据流通畅。
5. 深度拓展与利弊权衡 (Deep Dive & Trade-offs)
- 核心加分项：主动向面试官分析各种设计思路的利与弊（Trade-offs），证明架构思维的广度。
- 数据库选型：对比 SQL（支持 ACID 强事务）与 NoSQL（高并发水平扩展，Key-Value/Document 存储）的适用场景。
- 数据库分片（Sharding）：讨论按 Table 分拆的局限性，对比一致性哈希（Consistent Hashing）与按 Range/ID 分片的负载不均衡风险。
- 读写优化：引入 Redis 缓存层，并权衡缓存失效（Cache Invalidation）、缓存穿透与雪崩的解决机制。
面试过程中的软实力与避坑准则
- 不要与面试官争论 (Don’t Argue)：系统设计没有绝对唯一的正确答案。即使面试官的见解有偏差，求职者也应保持谦逊和技术弹性（如“在这个前提下您的方案更优，我们可以先按这个思路深入”），防止陷入自我 Ego 争执。
- 循序渐进的双向互动：避免唱独角戏。保持与面试官的密切互动，将其视为共同探讨方案的未来同事。
- 不要死记硬背：无脑套用经典案例（如 Grokking 课程里的标准解法）非常脆弱。一旦面试官微调限制条件，死记硬背者将无法逻辑自洽。
关联概念
- shared-design-concept — 共同设计共识
- career-development — 职业护城河
- sdlc-bottleneck-in-ai — 开发工具链瓶颈
- latticework-of-mental-models — 跨学科网格