举一个例子，说明你构建了一个工具或系统，其规模扩展到超出最初设计要求的10倍。

考察要点

这道题考察的是工程师的技术前瞻性（Foresight）和架构设计能力。面试官想看你是否能在满足当前需求的同时，为未来的不确定性增长预留扩展空间，而不是每次需求变化都推倒重来。

对于 Amazon，这道题重点考察以下 Leadership Principles (LP)：

1. Think Big: 你是否设计了一个能够支撑业务指数级增长的系统，而不仅仅是满足眼前的任务。
2. Customer Obsession: 系统的扩展最终是为了应对超预期的用户需求，体现了你对用户体验的执着。
3. Ownership: 你不仅仅是构建了系统，还持续为其性能和扩展性负责。

高分示范答案（STAR）

Situation（背景） 大约两年前，我在一家电商公司担任后端技术主管。当时我的团队（5名工程师）负责一个新项目：为头部KOL（网红主播）提供专属的直播间优惠券系统。项目初期，这只是一个针对Top 3主播的试点项目，设计目标是支撑他们直播高峰期约 500 QPS 的领券请求。

Task（任务） 我的任务是设计并实现这套优惠券系统的后端服务。核心要求是在 2 个月内上线，并能稳定处理 500 QPS 的峰值流量，同时确保券库存的准确性，不能超发。

Action（行动） 虽然初期目标只是 500 QPS，但我预见到如果项目成功，公司必然会将其推广到所有主播。所以我做出了几个关键的架构决策：

1. 我没有将优惠券逻辑耦合在主交易服务中，而是坚持将其构建为一个独立的微服务。 当时有同事建议为了快速上线直接在现有服务上加功能，但我认为优惠券的流量模式（瞬间高并发）与常规交易（平稳）完全不同，强行耦合会互相影响。我通过性能压测数据向团队证明，耦合方案会在直播高峰期拖垮主交易服务，最终说服了大家。

2. 在数据存储上，我做了一个权衡设计。 优惠券的总量和已发放量，我存储在 MySQL 中以保证数据最终一致性。但对于“库存扣减”这个热点操作，我引入了 Redis 来做预扣减（pre-deduction）。领券请求只操作 Redis，速度极快。然后我通过一个异步任务，将 Redis 的变更批量同步回 MySQL。这个设计在当时看是过度设计，但我判断这是未来扩展性的关键。

3. 我设计了无状态的服务节点，并将用户信息和会话状态存储在外部缓存中。 这意味着我们可以通过简单地增加服务实例（Pods）来水平扩展计算能力，而不需要担心状态同步问题。

Result（结果） 系统上线后稳定运行了 3 个月。后来公司战略调整，决定将该系统开放给平台上超过 2000 名主播。一夜之间，我们系统的目标流量从 500 QPS 飙升到 10,000 QPS。

由于我前期的架构设计：

• 我们仅用了一天时间，通过水平扩展服务实例，就将系统的承载能力从 500 QPS 提升到了 12,000 QPS，成功支撑了全平台主播的活动，P99 延迟始终保持在 50ms 以下。
• Redis 预扣减库存的方案完美应对了高并发写入，整个大促期间优惠券超发数为 0。
• 相比于如果当初采用耦合方案需要进行的为期数月的重构，我的方案至少为公司节省了 60 个工程师人天的工作量，并抓住了业务快速扩张的机会。我学到，好的架构不是过度设计，而是在关键节点做出有远见的选择。

低分陷阱（常见扣分点）

1. 把“扩展”简单理解为“加机器”：只说“我们加了更多服务器”或“我把 K8s 的 pod 数量调高了”，这体现不出你的架构设计能力，只能说明你会用运维工具。
   • 反例：“流量上来后，我们就把 EC2 实例从 4 个加到了 40 个，问题就解决了。”
2. 没有“10x”的意外性：讲一个按部就班、计划内进行扩容的故事，无法突出你在应对突发状况和前期设计远见上的能力。面试官想听的是“意料之外，情理之中”的扩展。
   • 反例：“我们计划今年用户翻倍，所以我们提前半年就开始做扩容项目，按计划完成了。”
3. Action 停留在表面，没有解释“为什么”：只说“我用了 Redis 和 Kafka”，不说你为什么用它们，解决了什么具体问题，做出了什么权衡。
   • 反例：“为了应对高并发，我们引入了缓存和消息队列。”（太笼统了，哪个高并发系统不用？）
4. 结果没有量化，或量化维度单一：只说“系统顶住了压力”或“项目很成功”，没有具体的 QPS、延迟、业务收入、节省成本等数据。
   • 反例：“新系统上线后，性能得到了很大提升，用户反馈很好。”

高概率追问（3 个 + 示范回答要点）

1. 追问：你当初为什么选择 Redis 做预扣减，而不是其他方案？有没有考虑过数据一致性问题？

   • 要点 1 (选型理由)：对比了其他方案。例如，直接操作数据库会因为行锁竞争导致性能急剧下降。而 Redis 的 INCR / DECR 是原子操作，单线程模型避免了锁的开销，性能极高，非常适合库存扣减这种“写多读少”的场景。
   • 要点 2 (一致性保障)：我设计了补偿机制来保障最终一致性。比如，通过一个后台对账服务，定期比较 Redis 库存和 MySQL 库存的差异，并进行修复。同时，如果 Redis 实例宕机，我们有从 MySQL 恢复 Redis 库存的应急预案，确保数据不错乱。

2. 追问：你说服同事和领导接受你“过度设计”的方案时，遇到的最大阻力是什么？你是如何克服的？

   • 要点 1 (识别阻力)：最大的阻力是项目时间和资源限制。我的方案需要额外引入 Redis，增加了开发和运维的复杂度，与项目“快速上线”的目标有冲突。有同事认为这是“镀金”，增加了不必要的风险。
   • 要点 2 (数据驱动)：我没有进行空洞的争论。我花了一天时间，用 JMeter 快速搭建了两个方案的原型进行压测。我用压测报告的数据清晰地展示：耦合方案在 300 QPS 时响应时间就开始飙升，而我的独立服务+Redis方案在 1000 QPS 下依然稳定。
   • 要点 3 (展示长期价值)：我向我的经理阐述，这个“额外”的工作是对未来的投资。一旦业务验证成功，我们能以极低的成本快速复制，而不是到时候再痛苦地重构。我将它包装成一个“可扩展性”的特性，而不是一个“技术炫技”。

3. 追问：如果让你重新设计这个系统，你会做哪些不一样的决定？

   • 要点 1 (做得更好的地方)：我会更早地引入全链路压测平台。当时我们的压测还比较原始，如果能从一开始就建立起标准化的压测流程和平台，后续的每次扩容和性能优化会更高效、更可信。
   • 要点 2 (技术选型反思)：当时为了快，Redis 集群是自建的。现在看，直接采用云厂商提供的托管 Redis 服务（如 AWS ElastiCache）会更好，能省去大量的运维和监控工作，让团队更专注于业务逻辑。这是在“拥有成本”和“开发速度”之间新的权衡。

故事复用建议

这个故事的核心是“用有远见的架构设计，应对突发的业务增长”。除了回答本题，它还可以稍作调整，用于回答以下问题：

• Tell me about a time you took ownership of a project. (你主动承担了确保系统未来扩展性的责任)
• Describe a situation where you had to influence others without authority. (你说服团队接受你的架构方案)
• Give an example of how you deliver results. (最终结果是系统成功支撑了业务增长，带来了巨大价值)
• Tell me about a time you made a decision with incomplete data. (在项目初期，你并不知道未来一定会扩展到 10x，但你基于经验和判断做出了决策)
• Describe a complex technical problem you solved. (整个架构设计和实现过程就是一个复杂问题的解决方案)