四道考判断而非考记忆的题。每组先说面试官在给什么打分，然后让你做一个决定——选项问的是「该先问什么、该拿什么去换」，不是「该画哪张图」。
系统设计是唯一没有标准答案的面试环节，这正是背架构图会失败的原因：追问永远是「如果流量是这个的十倍呢」，而背出来的设计不会拐弯。真正被打分的是：你能否把含糊的题目变成需求、能否说出每个选择的代价、以及能否修当前的瓶颈而不是所有可能的瓶颈。
这里的题都写成决策而非事实。每题都有站得住的答案，但解析的重点是面试官在听的那条推理——以及通常能拿到分的那一句话。
如果你在认真准备，把它和我们 SQL 页的数据层问题配着看：分片、复制与读路径正是系统设计和 SQL 知识交汇的地方，面试官会在两者之间自由跳转。
开场故意含糊。上来就画框的人已经在丢分；花三分钟把题目变成数字的人已经在得分。要问规模（日活、读写比、峰值倍数）、延迟预期、以及什么数据绝不能丢。这些答案决定了后面每一个选择，而把这层因果说出口，正是「设计出来的系统」与「背出来的系统」的分界。
通常怎么问：「设计一个短链服务」·「设计一个信息流」——故意含糊的开场
第 1 题
面试官只说了一句：「设计一个短链服务。」最强的第一步是什么？
更好的答法：B. 先问规模、读写比和延迟目标，并说明这些数字将如何驱动你的选择
🐱 先要需求，而且关键在于说出为什么要问：「如果读写比是 100:1，缓存就是设计的主心骨；如果写入很重，ID 生成策略才是。」这句话表明你懂得一个系统设计是有驱动因素的——那才是真正被打分的东西。选项 A 是最常见的失败模式；背下来的架构图答不了「如果量级涨十倍呢」，而这个追问一定会来。
「用 SQL 还是 NoSQL」没有正确答案，只有被论证过的答案。被打分的能力是能说出你放弃了什么：选强一致，就要在网络分区时付可用性的代价；上缓存，就继承了数据陈旧和失效难题；分片，跨片查询就变贵。在面试官追问之前先把代价说出口，后面就从考试变成了讨论。
通常怎么问：「用 SQL 还是 NoSQL？」·「CAP 对这个设计意味着什么？」·「缓存失效策略？」
第 2 题
你提出在数据库前面加一层缓存。接下来必须主动说出什么？
更好的答法：B. 失效策略，以及一次读到陈旧数据对这个产品意味着什么代价
🐱 缓存是一笔正确性上的交易，不是白送的提速：你选择了有时会提供旧数据。说清失效方式（TTL、写穿、写时显式失效），更重要的是说清这个产品能不能容忍陈旧读——粉丝数旧一点没事，账户余额旧一点就不行——这才把「加个缓存」从口号变成决策。选哪个库（A）是最没意思的部分，也很少被问。
第 3 题
关于 CAP，哪种说法在面试里说出来是站得住的？
更好的答法：B. 分区无论你愿不愿意都会发生；真正的选择是分区期间怎么办——拒绝写入（保一致）还是接受写入事后调和（保可用）
🐱 「三选二」是多数候选人背出来的版本，而它有误导性：在任何真实的分布式系统里，分区是既成事实、不是选项，所以 P 并不是你能拿去交换的东西。你真正要做的决定，是分区期间的行为。这样表述能显示你运维过分布式系统而不只是读过摘要——并且顺势引出关于最终一致性的追问。
扩容题有一个惯常顺序，因为读通常远多于写：先缓存，再读副本，再对写分片，最后拆服务。被打分的是你能不能指出当前的瓶颈，而不是一口气把四招全用上。说出哪个组件会先饱和、以及什么指标能告诉你——这就把购物清单变成了工程答案。
通常怎么问：「一千用户能跑。现在让它撑一千万。」·「最先崩的是哪儿？」
第 4 题
一个读多写少的服务开始变慢。哪种顺序体现了更好的直觉？
更好的答法：B. 先度量找出瓶颈，然后加缓存、再加读副本，只有当写成为约束时才分片
🐱 分片是最贵且最难回头的一步：它让每一个跨分区查询和每一个事务都变复杂，所以在读多写少的场景里应该排在最后，先拿便宜的收益。面试官在听的那个词是「度量」——先说出指标再给药方的人在描述工程，上来就分片或微服务的人在描述简历。选项 D 作为止血手段不算错，但要说清它买的是时间、不是解决方案。
从需求开始，并且说出口：规模、读写比、延迟目标、什么绝不能丢——再加一句这些数字将如何驱动你的选择。这三分钟能救下整场面试。
了解常见模式有帮助，但照背是个陷阱，因为它答不了「量级涨十倍呢」。该学的是组件及其代价：缓存、副本、分片、队列、CDN——以及每一个各自放弃了什么。
深到能避开「三选二」这种过度简化即可。分区是既成事实；要决定的是系统在分区期间的行为。光是这个表述就已经领先多数候选人。
没问就画。第二常见的是一口气把所有扩容手段都用上，而不说清你在解决哪个瓶颈、以及你会用什么指标去确认。