系统设计面试方法论：Scale 估算与高层设计

面试官抛出这道题的时候，你心里可能在想：又要设计 Twitter 了？

别慌。系统设计面试考的从来不是你能不能设计出 Twitter，而是你思考问题的方式。

就像老中医看病，先要望闻问切，再开药方。系统设计的第一步，永远是理解问题的边界。

为什么要 Scale 估算？

想象一下，你要去一个陌生的城市，你不知道它有多大，不知道有多少人口，你怎么规划路线？

Scale 估算就是给系统「量体温」——知道系统的规模，你才能判断该用什么方案。

例子：如果系统只有 100 个用户，你用 Redis 做缓存就是杀鸡用牛刀；但如果是 1 亿用户，不用缓存，系统分分钟被流量冲垮。

四步法：从模糊到清晰

第一步： Clarify Requirements——问对问题

面试官说「设计一个短链接系统」，你要问清楚：

• 每天生成多少短链接？
• 点击量是多少？
• 需要支持自定义短链接吗？
• 要支持分析统计吗？

这些问题决定了你后续的技术选型。

第二步： Capacity Estimation——量化规模

用 Back-of-the-Envelope 估算：

假设：
- 日活用户：1 亿
- 每天发微博量：5 亿条
- 每条微博 200 字节
- 需要存储 3 年

存储量 = 5亿 × 365 × 3 × 200 字节 ≈ 10 PB

看到 10 PB 这个数字，你就知道不能用普通数据库了。

第三步： High-Level Design——画框架

关键组件：

• Load Balancer：流量入口，分发请求
• API Gateway：统一入口，做鉴权、限流
• Storage：根据场景选 MySQL、Cassandra、HBase
• Cache：Redis/Memcached 做缓存层
• Message Queue：削峰解耦

第四步： Deep Dive——深入设计

针对具体问题深入：

• 如何做数据分片？
• 一致性如何保证？
• 缓存策略怎么设计？
• 怎么应对热点问题？

Scale 估算实战：Twitter 时间线

用户规模：
- 月活：3 亿
- 日发推：5 亿
- 日点击量：500 亿

存储估算：
- 每条推文 200 字节
- 需要存储 3 年
- 总存储量 = 5亿 × 365 × 3 × 200 = 10.95 PB

QPS 估算：
- 假设 30% 用户看时间线
- 日活 = 1 亿
- 每用户每天刷 10 次
- 读 QPS = 1亿 × 30% × 10 / 86400 ≈ 3500 次/秒
- 峰值 QPS = 3500 × 3 = 10500 次/秒

看到这个数字，你就知道需要：

• 缓存层来抗读流量
• 读写分离来分散压力
• 可能需要推送模式来优化延迟

面试中的沟通技巧

面试官不是想为难你，而是想看你的思考过程。

好的沟通方式：

• 「让我先确认一下系统的规模」
• 「如果用户量是 X，我预计 QPS 是 Y，存储量是 Z」
• 「基于这个规模，我建议采用 X 方案，因为...」

不好的沟通方式：

• 一上来就开始画架构图
• 不问规模就开始写代码
• 方案确定后不再讨论 Trade-off

总结

系统设计面试的核心不是「背答案」，而是「会思考」：

1. 问清楚问题：规模决定方案
2. 量化估算：用数字说话
3. 先框架后细节：从粗到细
4. 讨论 Trade-off：没有完美的方案

下次面试官问你设计 XX 系统，先深呼吸，然后说：

「在开始之前，我想先确认一下系统的规模...」