系统设计基础
大多数系统设计的失误并不是「架构天才没发挥」，而是「顺序错了」：还没问清楚真正的约束，就先选了方案。一个 3000 人用的内部工具不需要一套 Kafka 集群，而一个 4000 万用户的支付服务也不该跑在单台 Postgres 上。下面这棵决策树，就是一线工程师实际做设计题时怎么走的，它能帮你省下这一行最贵的错误——把小东西过度设计、把关键东西欠设计。这篇文章也常和高频面试题、后端岗位结合着看，搭配本站的data engineering basics（英文）能把数据面也补上。
怎么用五分钟搞砸一场系统设计面试
你可以把一家公司面试轮里的每道白板数据结构题都答满分，仍然在终面几分钟内翻车。最快的翻车方式：听到「设计一个短链接服务」，打开空白板，还没问一个澄清问题，就直接画「Database」「Cache」两个框。面试官考验的并不是你能不能背出 CAP 定理；他们在观察你在时间压力下怎么把模糊问题拆解成具体的取舍。而能过关的工程师，开头做的都是同一批事。这个例子拿短链接服务走一遍，因为它是行业里被问最多的一道系统设计题，并且它能把你要用到的每一项技能都照出来。
第一步：先划清范围，再画任何一个框
动手前先把需求定下来，否则你会设计错系统。要问清楚规模、延迟、读写比、约束。对短链接来说，十分钟版的问题问完，答案大致是这样：每年新增 50 亿条短链、每年约 200 亿次读取、读写比 10:1、重定向的 p99 延迟要低于 300 毫秒。这四个数字逼出了后面所有决策。把它们写在白板上。如果候选人一上来就画组件，面试官会注意到——区分「有经验的设计者」和「背模板的」最快方式，就是看前者拒绝盲画。想知道这些模糊性在限时场景里怎么展开，本站的 数据分析基础里面对需求量化的思路也可以迁移过来。
能加分的谈资
先估量。提前把粗略的 QPS 和存储估算做了，能让后面的选择站得住脚。以本例来说：一年 200 亿次读取约等于平均每秒 63 个请求，流量高峰时再乘十倍。把每一层都说出来：客户端、负载均衡、API 服务器、缓存、数据库、后台 worker。即使你不逐一展开，把它们列出来也说明你脑子里有完整形状。承认你在推迟什么：四十分钟内你完成不了限流、统计、自定义别名和删除逻辑，就明说哪些先搁置、为什么。
存储选型：取舍浮出水面的时刻
到这里，面试者开始分成两拨：能真正思考存储的，和在套模式的。短链接需要一张「短码 → 目标地址」的键值查找，而且读取量巨大。关系型存储直接放在 API 后面会被读放大压垮，所以标准答案是在数据库前面加一层缓存，用 Redis 或 Memcached 这种内存型存储处理热路径。写路径相比之下就非常简单了——每秒才 6 次写，放在 worker 后面用普通数据库就够了。
把短码生成器设计对
短码是 base-62 编码（a–z、A–Z、0–9），6 个字符大约能组合出 560 亿种，远超我们每年 50 亿个的目标。真正有工程味道的问题是：怎么在「单点计数器变成瓶颈」的前提下保证唯一性。Snowflake 式生成器预留了 41 位时间戳、机器 ID 和序列号，让每台服务器都在本地零协调地铸造唯一 ID。如果你随机生成再查冲突，就得加重试逻辑，而规模一上来这种检查就是浪费。真正的教训：选一种把冲突问题「消除掉」的方案，而不是「事后响应」的方案。
缓存与一致性哈希
一旦读占主导，缓存就不是可选项了。在 10:1 的读写比下，95% 的缓存命中率意味着每秒只有约 3 个请求真正落到数据库——这往往是「单台普通实例」和「一整支机群」的区别。微妙的部分是缓存失效和键分布。一致性哈希把键铺到各节点，同时把节点故障或新节点加入时的重排量降到最低；你还要在 write-through、write-around、write-back 之间做选择。对这个负载来说，write-through 是最安全默认，它让缓存保持权威，重定向读到的过期数据最多只会在 TTL 窗口内。
| 缓存策略 | 适用场景 | 风险/代价 |
|---|---|---|
| Write-through（写穿） | 读多写少、一致性要求高 | 写延迟略增，数据最可靠 |
| Write-around（写绕） | 写后不一定立刻被读 | 可能读到旧值，命中率受影响 |
| Write-back（写回） | 写密集、能承受短暂不一致 | 宕机可能丢数据，需权衡 |
顺带一提，如果投后端或基础设施岗，扎实的 Python 自动化脚本功底对理解主机、内存限制和缓存容量会很有帮助。
负载均衡、无状态化与可用性的成本
你加的每个组件都有得有失。在 API 服务器前面加个负载均衡，换来横向扩缩容和健康检查式故障转移，代价只是少量额外延迟。把 API 层做成无状态，负载均衡才能把任意请求发给任意机器——这就是为什么会话状态不该留在应用层。真正贵起来的是数据库的可用性：加一个副本换来读吞吐和故障转移，却引入了复制延迟，也让写入因为必须为主库定策略而变得更复杂。能让面试官眼前一亮的诚实框架是：可用性是一道光谱，不是一个开关。单节点跑副本，和为了 99.99% 的可用性付出复杂架构的代价，是两回事。想把这套工程视野再拓宽，可以看 Web 开发入门里的分层与部署思路。
常见问题
面试时该不该背 CAP 定理？
不该死背。能讲出「你选择的系统在哪个角落在容错和一致性上做了取舍、为什么」比背出三个字母有用得多。面试官想看你怎么在具体需求下做权衡。
所有设计题都要先在白板上套这些步骤吗？
对大部分是。范围 → 估算 → 分层 → 存储 → 关键机制 → 权衡，这套骨架几乎通吃。真正的高手会在不同题里调整重心，而不是机械照搬。
缓存命中率到底要多高？
读多场景下 90% 以上通常是基准线，95% 就很舒服。低于 90% 先查是键设计不合理还是淘汰策略不对，而不是一味加缓存节点。
短链的写路径真的那么简单吗？
对。真正的工程挑战几乎全在读路径和键唯一性上。写每秒几笔，正常数据库完全扛得住，没必要为它设计复杂架构。判断「哪里才是瓶颈」正是这套方法的核心。
延伸阅读
往下沉一层：llm application development（英文）讲大模型应用的设计权衡，database design principles（英文）补存储选型，则提供更多工程与效率向的内容供搭配。