Amazon Principal：现有系统六个月后哪里会坏？不增人怎样改？

题目重点：用约束、证据与风险排序做Architecture Review，给可执行迁移和停止线。

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

来源明确architecture review问六个月风险、over-engineering、headcount不增怎么改；原口述系统未公开。本文评审方法与示例都是训练。
不能没数据就判断“用了微服务所以错”；先确认用户旅程、SLO、增长、发布节奏、依赖和运维容量。
团队人数固定意味着迁移/运行/维护总工作都受限，不等同只约束开发排期。

先画一条关键请求和一条数据写入/恢复路径，列组件owner、存储真值、重试边界与故障传播。核业务损害最大的状态，不从技术组件清单按个人喜好逐个批评。
六个月风险用已观测增长推容量范围：排队等待、DB连接/索引、热key、重试放大、存储保留与恢复耗时；同时看证书/版本到期和单人知识依赖。预测给假设与置信区间，明确什么证据会推翻判断。
区分已有事故、可复现瓶颈与推测风险，按影响×发生可能/时间窗口排序，再看改动成本与可逆性。高影响未知项先测量，不能把所有unknown塞入P0清单制造恐慌。
over-engineering表现为没有需求支撑却持续带来操作/学习成本的机制，例如低并发内部工具仍有复杂多区调度；但若有明确恢复/合规目标，多区并不是过度设计。评审给删除或简化方案的实际代价。
无新增headcount时先减少toil和故障面，限制不必要功能/定制，改重试/超时/队列上限通常比全量重写更易交付。把紧急容量保护、短期修补、长期演进分阶段，给owner/日期/验证与停止线。
迁移靠兼容接口、影子读/小流量、状态对账和rollback；双写并不天然一致，明确主真值与补偿。成功不只“新版上线”，还看运维负担、用户错误和后续变更速度是否改善。

假设连接池上限500，当前峰值400，月峰值增长20%；两个月400×1.2²=576超上限，而“六个月后才改”来不及。先限制请求并发/退避重试、核连接持有时间，再决定索引或存储迁移；峰值模型不包含所有瓶颈，所以还需压测与事故回放。

评审成本按关键旅程/依赖图与证据收集，不给固定算法大O；运行容量以峰值λ、平均服务时间W、并发λW等基础估计，再用尾延迟和排队测量校准。迁移工作量含新旧共存，不只新代码行数。