Outbox与跨库一致性

双写中间总有一个失败窗口

关系库更新文档状态之后，向量服务可能超时；先写向量再写关系库，也可能留下没有权威身份的孤立索引。两个系统各自成功的接口并不提供跨系统事务。需要明确哪个系统权威、事件如何传播、消费者如何处理重复，以及怎样发现持续落后的索引。

AWS公开的transactional outbox模式把业务变更和待发送消息写入同一事务，后续由发布者转发事件。这样数据库提交与待发布记录一起存在，但消费者仍须幂等，事件也不天然保证所有下游按相同顺序完成。

用对象版本拒绝旧事件

建议事件包含event ID、source object、期望版本、操作类型和generation。消费者写入前比较当前期望状态，避免乱序的旧更新覆盖新版本。完成后记录实际索引版本和处理结果；失败事件进入可观察重试队列，而不是无限静默重试。

删除与权限撤回宜先在权威层禁用，异步消费负责清理。若允许较旧内容继续服务，应明确只针对普通内容更新，并给出新鲜度；不能把同一最终一致窗口扩展到敏感权限。读取服务需要能拦截尚未传播的撤回。

对账是机制的一部分

逐对象比较权威版本和检索generation，检查缺chunk、旧chunk、孤立向量与漏删除。系统应知道每个索引当前落后多久、哪些对象失败，以及重放从何处继续。只监控消息队列长度不足以证明索引内容正确。

验收主动制造提交后崩溃、发布后未确认、重复消费、乱序、外部服务失败与索引全量重建。正确结果不是事件只出现一次，而是重复与恢复不会改变最终合法状态。任务checkpoint可以记录传播进度，但不能替代实际下游读回与对账。