系统设计面试：别在估算容量时死磕精确度

很多人在系统设计面试里栽跟头，不是因为数学不好，而是因为他们把估算当成了数学题，而不是设计工具。最典型的错误就是低头心算半天，憋出一个没人能验证的数字，然后就把这个数字扔在角落里，接下来的面试完全不提它。

其实估算容量（Capacity Estimation）根本不是在考你算术，面试官想看的是：你能不能在方案敲定前判断这玩意儿在物理上可行？你知不知道真正的瓶颈在哪——是存储空间、读吞吐量、写吞吐量，还是带宽？

如果你算出读请求是 30k/sec 而写请求只有 200/sec，这个量级差直接决定了你的架构怎么走；但如果你算出需要几个 PB 存储然后就没下文了，那你只是做了一次毫无意义的乘法。

核心技巧：暴力舍入

在面试这种高压环境下，追求精确就是给自己挖坑。你不需要一份精准的容量计划，你只需要确定数量级。

最实用的一个替代方案就是把一天的时间直接看作 10^5 秒：

1 day = 86,400 seconds ≈ 10^5 seconds

虽然有 16% 的误差，但它能让你在脑子里瞬间完成除法，而且没哪个面试官会纠结这几千秒的差距，但他们绝对会注意到你花 40 秒在纸上做长除法。

另外几个建议背下来的量级：

• 100万次请求/天 ≈ 12次/秒（直接估算成 10）
• 1 KB × 100万 = 1 GB
• 1 KB × 10亿 = 1 TB
• 峰值流量 ≈ 平均值的 2-3 倍
• 副本存储 ≈ 原始数据的 3 倍

逻辑链路：单向推导

估算的路径必须是线性的：用户数 → 请求数 → QPS → 存储 → 带宽。千万不要跳跃。每一步假设都要大声说出来，这样如果你的前提错了，面试官能立刻纠正你，而不是看着你在沙堆上盖大楼。

拿设计一个社交 Feed 流举例，假设日活（DAU）1 亿。

明确假设（不要偷偷心算）：

• 每人每天发 0.2 条状态
• 每人每天刷 10 次 Feed
• 每条状态含元数据约 1 KB
• 每次刷 Feed 显示 20 条

写操作计算：

100M * 0.2 = 20M posts/day
20M / 10^5 = 200 writes/sec
Peak (3x) = 600 writes/sec

读操作计算：

100M * 10 = 1B feed loads/day
1B / 10^5 = 10,000 reads/sec
Peak (3x) = 30,000 reads/sec

存储计算：

20M posts/day * 1 KB = 20 GB/day
20 GB * 365 = ~7 TB/year
7 TB * 3 (replication) = ~21 TB/year

峰值带宽：

30,000 reads/sec * 20 posts * 1 KB = 600 MB/s

关键点：用数据反推架构

算完之后，重点是分析这些数字排除了什么。

首先，读写比是 50:1。这种极端的非对称性决定了整个设计方向：应该在写路径上多花功夫（因为写少），在读路径上尽量轻量化。比如采用写时扇出（Fan-out on write）预计算 Feed，而不是在读时实时聚合。

其次，一年 21 TB 的副本存储量其实很小，几台机器就搞定了。这意味着存储根本不是瓶颈，你不需要在面试中浪费时间去详细讨论复杂的存储分片策略。

最后，600 MB/s 的峰值出向带宽虽然不小，但 CDN 和缓存层完全能扛住。

所以，真正的瓶颈是读 QPS，整个设计应该围绕如何吸收这个压力来展开。这就是估算的意义——用几行简单的算术推导出架构结论。

决定生死的时间量级

吞吐量决定“量”，而延迟（Latency）决定“可行性”。不需要死记硬背，但要记得比例关系：

• L1 缓存： ~1 ns
• 主内存： ~100 ns
• NVMe SSD 随机读： ~50–100 µs
• 数据中心内部往返： ~0.5 ms
• 机械硬盘寻道： ~5 ms
• 跨洲际往返： ~150 ms

你要意识到内存比 SSD 快一千倍，跨洲际调用比内网调用慢三百倍。如果你设计一个方案需要在 200ms 预算内完成三次顺序的跨地域调用，那这个方案在物理上就是死路一条