把业务数据和待发送事件放进同一个本地事务，可以帮助避免业务成功却没有留下投递记录的问题。但 Outbox 还需要后台投递、状态维护、重试和清理，不能只建一张表就结束。
明确投递记录的生命周期
记录事件标识、业务关联、创建时间、尝试次数和投递状态。多个投递实例要有合理的认领规则，失败后能够恢复。发送成功但状态更新失败时，仍可能再次发送，因此消费者需要幂等。
观察最老未投递时间
总条数之外，检查积压时长、失败原因和不同事件类型的处理能力。少量关键事件长期未发送，比大量短暂排队更值得关注。告警需要对应具体处理入口。
清理与重放分别设计
已完成记录的保留期应满足核对需求；未完成记录不能仅按日期删除。重放时确认业务效果、消费者兼容和去重规则，避免把历史事件当成新的业务操作。
验收数据库与消息设施分别故障
测试事务提交后消息设施不可用、投递成功后进程退出等情况，核对业务不会丢失追踪。恢复速度也应评估，避免积压只能靠人工逐条处理。
常见问题：Outbox 能保证业务恰好执行一次吗？
不能自动保证。它改善本地业务与待投递记录的一致性，跨系统仍要处理重复、顺序和最终状态。
技术参考：微软：Saga 模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。