Transactional outbox与Event Sourcing模式差异及适用场景对比

这俩模式解决的根本不是一个层面的问题，很多人误以为是竞争关系纯粹是因为二者都会产出事件，实际上核心逻辑差得很远：

• Transactional Outbox（事务发件箱）本质是个跨服务通信的可靠性补丁，它的唯一核心目标是解决「本地数据库事务提交」和「事件/消息发送到MQ」的原子性问题，不改变你原有业务数据的存储方式。你该怎么存业务当前态就怎么存——订单表照样存订单状态、金额、用户ID这些最新值，只是同库多建一张outbox表，业务操作执行的时候，和业务数据更新放在同一个本地事务里，把要发的事件先写到outbox表，事务提交成功后，再靠独立的后台进程（定时扫表/CDC订阅）把outbox里的事件投递到消息队列，投递成功就标记为已发送或者直接归档。它从头到尾都不要求你把事件当数据源，事件只是用来通知其他服务的载体。
• Event Sourcing（事件溯源）本质是完全替换了业务状态的存储模型，它的核心是把事件作为唯一的事实来源，根本不存业务实体的当前状态。比如你要查一个订单的当前状态，不是直接select订单表拿现成值，而是把这个订单从创建开始的所有事件（创建、支付、发货、确认收货……）按顺序挨个回放，计算出当前的状态值。它的核心价值是完整不可篡改地记录所有状态变更轨迹，天然支持全链路审计、任意时间点状态重建、复杂业务逻辑推演，对外发布事件只是它的附带产出，不是核心目的。

一句话就能分清楚：用Outbox的时候，你的业务数据是“存当前态，发事件当通知”；用Event Sourcing的时候，你的业务数据是“存全量事件，当前态靠算”。

首先先纠正一个常见误区：这俩不是二选一的互斥关系，很多Event Sourcing的落地实现里，事件存储本身就承担了Outbox的作用，用来做事件的可靠投递。具体选型完全看你的业务诉求，别为了上模式而上模式：

• 只需要解决微服务间事件投递不一致、丢消息的问题，业务没有强留痕、状态回溯的硬需求，直接选Transactional Outbox，别碰Event Sourcing。
  举个最常见的例子：普通电商的订单流程，订单支付成功后需要同步给积分服务加用户积分、给通知服务发支付成功短信。如果直接在业务代码里事务提交后发MQ，很容易出现两类问题：要么业务事务回滚了MQ消息已经发出去，导致没支付的订单也加了积分；要么业务事务提交成功了，MQ发请求的时候网络闪断，消息丢了，用户付了钱没收到货也没收到短信。这时候用Transactional Outbox就刚好：在更新订单状态为“已支付”的同一个本地事务里，往outbox表插一条「订单XXX已支付」的记录，事务要么一起成功要么一起回滚，根本不会出现状态和事件不一致的问题。后面单独起个轻量的扫表进程，把outbox里没投递的事件发到MQ，发成功就打个标记。整个实现逻辑简单，团队只要会写普通CRUD就能维护，没有额外的复杂度，90%的常规业务场景用这个方案就足够。
• 业务对状态变更可追溯性有强合规要求，或者业务状态极复杂、需要频繁回溯任意时间点的状态、排查问题需要完整的变更链路，再考虑选Event Sourcing。
  举个典型例子：银行核心账务系统、证券交易系统、合规要求高的医疗病历系统。这类场景根本不允许你直接update覆盖原有数据——用户账户的每一笔资金变动、病历的每一次修改、证券的每一笔委托成交，都必须永久留痕，不能篡改，还要能随时拿出任意历史时间点的完整状态，出了错账要能顺着变更链路一步步倒推问题根源。这种场景下Event Sourcing是非常合适的选择：所有状态变更都以不可修改的事件形式存在事件库，要审计直接拉全量事件流，要查历史状态直接重放到对应时间点的事件就行。但要提前踩坑：上Event Sourcing必须配套做状态快照（不然事件攒到几百万条，每次重放算状态要几秒甚至几分钟，根本扛不住并发）、事件结构版本兼容（业务迭代改了字段，几年前的老事件怎么适配新逻辑）、最终一致性延迟处理，团队的学习和维护成本比普通CRUD+Outbox高很多，普通业务硬上纯属给自己找事。
• 如果是上面说的需要事件溯源的场景，同时还要把事件可靠投递给下游服务，直接把事件存储当Outbox用就行，不用单独再建Outbox表，两个模式的能力可以叠加，不存在冲突。

内容的提问来源于stack exchange，提问作者user2691719