题目重点：资源数据库变更后通过通知触发 diff 抓取和存储，设计版本水位、乱序、重试、权限与可重放审计。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版每个 resourceId 有单调 version，变更通知含 resourceId、fromVersion、toVersion 或可查询版本指针；这些字段是可行契约，不是题目已给。
- diff API 能读取指定版本间差异且历史保留足够覆盖消费者重试；若只可读 latest，必须改用源库 CDC/outbox 捕获变更事实。
- 不同资源间允许最终一致，但同一资源版本变更的审计顺序不能因通知乱序而失真。
解题路线
- 在资源写事务内同步写 outbox 或由可信 CDC 读取 commit log，再异步发 notification；不能先改库后单独发消息且仍宣称绝不漏通知。
- 消费者按 resourceId 分区顺序处理；收到 v3→v4 时若本地只有 v1，先补 v1→v3 或重取快照后记录 gap，不把 v4 误当紧接 v1。
- 用 (resourceId,toVersion) 或源事件 ID 做幂等键，diff 记录同时保存前后版本、变更字段、源时间、抓取时间、校验和和可见权限；重复投递只产生一条审计事实。
- diff 查询失败以指数退避重试并保留死信；源版本已过保留期时明确标记不可重建并请求快照/人工处置，不能编造丢失字段。
- 按资源类型、租户、时间分区索引查询；事件量高时可批量拉取 diff，但同资源仍须保证顺序。权限继承资源 ACL，敏感字段加密与审计读取。
- 做源库版本水位与目标库最高连续版本对账，定期抽样重建资源当前状态，监控 notification lag、gap、重试和 diff 不一致。
手动走一遍
资源 R 已保存 v1，消息 v3 到达而 v2 延迟：消费者暂不把 v3 差异当完整历史；拉取 v1→v2、v2→v3 后推进水位，之后迟到的 v2 通知按幂等键忽略。若历史 diff API 只留最近一分钟，而消息延迟十分钟，则须依赖 outbox/CDC 日志或承认历史缺口。
规模与取舍
N 次变更至少需 O(N) 差异记录；每条处理成本与 diff 大小 D 成正比，总数据量 O(ΣD)。按 resourceId 分区可横向扩容，但极热单资源会形成顺序瓶颈；实际吞吐由变更率、平均 diff 大小与保留期决定。
易错点与追问
容易失分的边界
- 数据库提交与发通知之间没有原子衔接，崩溃会永久漏事件。
- 收到通知后只查最新状态，跳过中间多次变更。
- 把投递顺序等同源库版本顺序。
- 差异历史已经过期却仍声称能恢复精确旧值。
- 只保留 diff 文本而没有资源版本和权限元数据。
继续深挖
- 如果源库无法提供历史版本或 CDC，怎样调整产品承诺？
- 资源删除与重建使用同一 ID 时如何区分 incarnation？
- 两个区域同时写同一资源怎样定义版本全序？
- 如何验证审计库与源库当前状态一致？
