标准答案
- 先说明用户影响和业务背景，例如高峰期接口 P99 上升、订单失败或消息积压，而不是从使用了什么组件开始。
- 展示排查证据和根因，例如 Trace、慢查询、队列长度或发布时间线，区分表象和真正瓶颈。
- 说明为什么选择限流、缓存、连接池隔离、索引优化或异步化，以及没有选择其他方案的原因与代价。
- 用改造后的错误率、延迟、容量、恢复时间或人工介入次数说明结果，并诚实说明仍需持续观察的边界。
题目解析
案例的价值在于说明你如何定义问题、收集证据、控制风险和验证效果，而不是罗列背过的中间件特性。
案例不需要夸大。小范围但有完整闭环的改造，比没有数据支撑的“百万 QPS 架构”更可信。
常见误区
- 只说“加了 Redis、MQ、K8s”，没有说明每项解决什么问题。
- 把一次偶发故障的临时止血说成长期根治。
- 没有量化结果或验证方式，无法判断改造是否有效。