name: design-interview-methodology description: 系统设计面试的4步框架。适用于准备技术面试、练习白板设计或组织架构讨论。涵盖需求收集、高级设计、深度探讨和总结。 allowed-tools: Read, Glob, Grep
设计面试方法论
这个技能提供了一个结构化框架，用于应对系统设计面试和架构讨论。
何时使用这个技能
关键词： 系统设计面试，白板设计，架构讨论，技术面试，设计框架
在以下情况使用这个技能：
- 准备系统设计面试
- 组织白板架构会议
- 教导他人如何应对设计问题
- 练习设计练习
- 与利益相关者领导架构讨论
4步框架
系统设计面试通常持续45-60分钟。这个框架确保你覆盖所有方面，同时展示结构化思维。
| 步骤 | 时间 | 目的 |
|---|---|---|
| 1. 需求收集 | 5-10分钟 | 澄清范围、约束、规模 |
| 2. 高级设计 | 10-15分钟 | 绘制主要组件和数据流 |
| 3. 深度探讨 | 15-20分钟 | 详细探讨1-2个关键组件 |
| 4. 总结 | 5-10分钟 | 权衡、瓶颈、改进 |
步骤1：需求收集（5-10分钟）
目标： 在设计前理解要构建什么和约束条件。
功能需求
询问核心功能：
- “主要用例是什么？”
- “用户应该能做什么？”
- “必须具备功能与可有可无功能是什么？”
非功能需求（NFRs）
澄清质量属性：
| 类别 | 要问的问题 |
|---|---|
| 规模 | 有多少用户？日活跃用户/月活跃用户？读/写比率？ |
| 性能 | 延迟要求？吞吐量目标？ |
| 可用性 | 正常运行时间要求？（99.9% = 每年8.76小时停机时间） |
| 一致性 | 强一致性还是最终一致性？ |
| 持久性 | 数据丢失容忍度？备份要求？ |
快速估算
快速计算以指导设计：
示例：设计一个URL缩短器
用户：1亿月活跃用户
写入：1亿URL/月 = ~40写入/秒
读取：10:1比率 = 400读取/秒
存储：1亿 * 500字节 = 50GB/月 = 600GB/年
详细估算技术： 参见 estimation-techniques 技能。
需求检查清单
在继续设计前：
- [ ] 确定核心用例
- [ ] 理解规模（用户、数据、请求）
- [ ] 已知读/写比率
- [ ] 设定延迟/吞吐量目标
- [ ] 清晰一致性要求
- [ ] 建立可用性目标
步骤2：高级设计（10-15分钟）
目标： 绘制主要组件并展示数据流。
从简单开始
从最简单的可能工作架构开始：
客户端 --> API网关 --> 服务 --> 数据库
然后根据需求添加复杂性。
要考虑的核心组件
| 组件 | 何时包含 |
|---|---|
| 负载均衡器 | 多服务器，水平扩展 |
| API网关 | 认证、速率限制、路由 |
| CDN | 静态内容，全球用户 |
| 缓存 | 读密集型，延迟敏感 |
| 消息队列 | 异步处理，解耦 |
| 数据库 | 持久存储（SQL vs NoSQL决策） |
| 搜索 | 全文搜索，复杂查询 |
| 对象存储 | 大文件，媒体内容 |
数据流叙述
逐步解释系统：
"当用户创建短URL时：
1. 请求命中负载均衡器
2. API网关验证请求并检查速率限制
3. 服务生成唯一短代码
4. 短代码和URL存储在数据库中
5. 更新缓存以快速读取
6. 响应返回缩短的URL"
API设计
草绘关键API端点：
POST /urls - 创建短URL
GET /{shortCode} - 重定向到长URL
GET /urls/{id}/stats - 获取点击分析
数据库模式草绘
显示关键表/集合：
URLs表：
- id: 主键
- short_code: 索引，唯一
- long_url: 原始URL
- user_id: 外键
- created_at: 时间戳
- expires_at: 可空时间戳
步骤3：深度探讨（15-20分钟）
目标： 在1-2个关键组件上展示深度。
如何选择深度探讨内容
让面试官指导，或基于以下选择：
- 最复杂组件 - 展示技术深度
- 对需求最关键 - 展示理解
- 你的优势领域 - 发挥你的专长
常见深度探讨主题
| 主题 | 涵盖内容 |
|---|---|
| 数据库扩展 | 分片策略、复制、索引 |
| 缓存 | 缓存策略、失效、命中率 |
| 数据一致性 | 冲突解决、分布式事务 |
| 搜索 | 索引、排名、查询优化 |
| 消息传递 | 交付保证、排序、死信 |
| 速率限制 | 算法选择、分布式实现 |
深度探讨示例：URL缩短器ID生成
选项1：自增
优点：简单，保证唯一
缺点：可预测，单点故障，难以扩展
选项2：UUID
优点：无需协调
缺点：太长（36字符），不URL友好
选项3：Base62编码计数器
优点：短，URL友好
缺点：分布式系统需要协调
选项4：预生成ID
优点：快速，无需运行时协调
缺点：ID耗尽，更复杂
推荐：预生成ID范围 + Base62编码
- 每个服务器获得一个ID范围
- ID使用Base62编码为短URL
- 处理分布式规模，无需每个请求协调
量化权衡
始终用具体数据解释权衡：
- “这增加了约5ms延迟，但将可靠性从99%提高到99.9%”
- “这使用3倍更多存储，但将查询时间从100ms减少到10ms”
- “这增加了复杂性，但允许水平扩展到10倍流量”
步骤4：总结（5-10分钟）
目标： 总结、识别问题并提议改进。
识别瓶颈
当规模增加时，系统首先会在哪里崩溃？
"主要瓶颈是数据库。在当前规模10倍时：
- 写入吞吐量成为限制因素
- 解决方案：按URL前缀实现分片
- 备用方案：为分析查询使用读副本"
讨论所做权衡
总结关键决策和替代方案：
"我们为重定向缓存选择了最终一致性：
- 好处：较低延迟，较简单架构
- 成本：可能最多5秒的陈旧数据
- 替代方案：强一致性，但更高延迟"
提议改进
如果有更多时间，你会添加什么？
| 改进 | 好处 |
|---|---|
| 分析管道 | 使用洞察，业务价值 |
| 滥用检测 | 恶意/垃圾URL保护 |
| 地理分布 | 全球较低延迟 |
| A/B测试能力 | 功能实验 |
处理边缘情况
提及你会处理的边缘情况：
- 如果数据库宕机怎么办？
- 如果URL在重定向过程中过期怎么办？
- 如果恶意用户垃圾邮件URL创建怎么办？
- 关于重复长URL怎么办？
常见陷阱避免
1. 跳跃到解决方案
问题： 在不理解需求的情况下开始设计。 修复： 先花5-10分钟在需求上。
2. 过度工程
问题： 添加你知道的每个组件。 修复： 从简单开始，仅当需求合理时才添加复杂性。
3. 不量化
问题： 模糊陈述如"它很快"或"它能扩展"。 修复： 使用数字：“处理10K请求/秒，p99延迟50ms”。
4. 忽略权衡
问题： 仅呈现设计的优点。 修复： 主动讨论每个决策的牺牲点。
5. 沉默设计
问题： 不解释就绘制。 修复： 不断叙述你的思维过程。
面试信号：面试官寻找什么
积极信号
- 在设计前询问澄清问题
- 从需求开始，而非解决方案
- 用快速估算量化规模
- 解释每个决策的权衡
- 主动识别瓶颈
- 承认不知道的内容
红色标志
- 跳跃到喜欢的技术而无需正当理由
- 忽略规模/性能要求
- 不能解释为何需要某个组件
- 不考虑失败场景
- 无法识别权衡
- 被挑战时防御性
时间管理技巧
| 情况 | 回应 |
|---|---|
| 时间不足 | 跳到总结，总结权衡 |
| 面试官重定向 | 跟随他们的引导，他们正在引导你 |
| 卡在某个组件 | 承认，继续，如果时间允许再回来 |
| 问及未知技术 | 解释你的推理，询问约束 |
练习策略
面试前
- 学习常见设计问题（参见
design-problem-catalog技能 - 第4阶段） - 练习快速估算（参见
estimation-techniques技能） - 了解你的质量属性（参见
quality-attributes-taxonomy技能） - 计时练习问题
练习中
- 设定45分钟计时器
- 在白板或纸上练习（非IDE）
- 大声叙述你的想法
- 记录自己并回顾
相关技能
estimation-techniques- 规模的快速估算quality-attributes-taxonomy- NFRs和"属性"cap-theorem- 一致性/可用性权衡（第2阶段）design-problem-catalog- 常见面试问题（第4阶段）
相关命令
/sd:design <problem>- 交互式设计会话（第4阶段）/sd:estimate <scenario>- 容量计算/sd:explain <concept>- 解释任何概念
相关代理
system-design-interviewer- 模拟面试练习（第4阶段）capacity-planner- 快速估算architecture-critic- 挑战你的设计（第4阶段）
版本历史
- v1.0.0 (2025-12-26): 初始发布
最后更新
日期： 2025-12-26 模型： claude-opus-4-5-20251101