题目重点：Staff Phone Screen 短 SD 问用户修改信息后的数据流；按源数据、事务事件、缓存/搜索投影和乱序修复回答。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版用户修改公开头像/昵称字段；邮箱、身份证等高敏字段要额外验证和限制传播，不能一概同流程。
- Profile Service 数据库为写入真相，搜索/推荐/缓存为派生读模型；UI 是否需 read-your-writes 由产品需求决定。
解题路线
- 入口核身份、字段级权限、schema 与版本/ETag，数据库事务写 Profile 和 outbox 事件，返回新 version；重复 requestId 幂等。
- outbox 稳定投递 ProfileUpdated(userId,version,changedFields)，消费者按版本更新搜索索引、缓存和其他读模型；同用户消息乱序时只应用较新版本。
- 发起者刚保存后读自己资料可回主库或使用写后缓存更新，其他服务允许短时间最终一致并展示更新时间；数据删除/可见性收紧要走更严格的失效与审计。
- 失败消费者重试、死信与重放；定期从主库版本对账读模型，防事件永久丢失。监控传播延迟、版本落后、缓存命中和隐私字段越权。
- 在 5 分钟回答里先画主写→事件→两类读路径，再选择一个一致性/失败边界深挖，不铺过多无题目证据的系统。
手动走一遍
训练例：用户把昵称从 A 改 B，主库写 version 12 并回显 B；搜索服务若先收到 version 12、后收到旧 version 11，应忽略 11。若更新搜索失败，事件仍在 outbox/队列可重放，而 UI 本人的资料页可读主库看到 B。
规模与取舍
主写与 outbox 约常数次数据库操作，每个下游事件处理成本与消费者数成正比；传播 p99 取队列积压和消费者能力。题目无 QPS/一致性 SLA。
易错点与追问
容易失分的边界
- 数据库写成功但直接 publish 失败，读模型永远旧。
- 旧版本事件覆盖新值。
- 把敏感资料广播给所有消费者。
- 缓存失效失败无对账。
- 只说‘更新 DB’没描述用户看到什么和失败后怎样恢复。
继续深挖
- 用户保存后立即搜索不到新昵称怎么办？
- 隐私可见性从公开改私密时能否容忍最终一致？
- 资料字段不同是否应分 Topic？
- 如何保证删除请求传播？
