题目重点：用事实链回答项目背景、本人技术选择、结果和跨团队协作，准备架构与故障追问。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 选择候选人真实做过且能解释设计细节的项目，能区分个人决策、团队贡献和外部依赖。
- 若没有可量化业务指标，用可靠的技术/用户反馈证据，不杜撰百分比。
解题路线
- 把故事压成：背景与目标、约束与初始基线、本人负责的决策、两种替代方案、实施与故障、结果和复盘。先讲清系统边界/数据流，再给个人行动，避免把项目摘要当答案。
- Staff/Infra 追问通常沿关键写路径、读路径、故障恢复和容量瓶颈走。准备架构图时标具体状态所有者、幂等/事务边界、监控水位与回滚手段；对不熟的组件坦诚说明谁负责。
- Impact 证据分三层：直接技术指标（p99、错误率、成本）、业务/客户结果和组织影响（复用/跨组决策）。任何数字要说明统计窗口、baseline 与测量方式，不能只给‘提升 50%’。
- 跨组过程讲清哪两方目标冲突、自己提出什么评估标准、谁最终拍板和事后结果。若方案失败，指出当时合理依据、警报阈值与改进，而非把失败归咎外部团队。
手动走一遍
回答骨架：‘目标 [具体 SLO]；当时方案 A 的瓶颈是 [证据]。我负责 [本人决策]，比较 B/C 的 [延迟/成本/风险] 后选 B；和 [协作方] 协定接口与回滚；结果 [真实测量]，但 [剩余限制]。’若面试官追问一致性，就画请求到存储/回调的顺序而不是重述 STAR。
规模与取舍
行为/项目深挖没有固定 Big-O；若项目涉及算法或存储，应按真实实现单独分析数据规模、尾延迟和故障恢复。准备时至少核对一个正常流与一个失败流。
易错点与追问
容易失分的边界
- 全程用‘我们’而说不出本人决策。
- 只说技术栈，不解释目标和权衡。
- impact 数字无口径/测量窗口。
- 跨组故事只讲‘沟通了’，没有冲突与决策结果。
- 不知道项目失败/回滚路径。
继续深挖
- 如果重做会换哪个设计？
- 哪项结果能归因于你的变更？
- 关键依赖故障时用户看到什么？
- 反对方案的人担心什么？
- 你在其中的不可替代贡献是什么？
