顾客付款后看到“下单成功”，仓库却始终没收到订单。这类故障往往不是订单丢了，而是订单已写进数据库，发送到 Kafka——供库存、支付和通知服务读取的事件流平台——的消息因宕机或网络问题没发出去。两步操作彼此独立，便留下了最隐蔽的“双写缺口”。
Transactional Outbox 的做法，是把订单记录和“待发送事件”放进同一个数据库事务——要么一起写入，要么都不写；后台程序再把事件转发到 Kafka。它封住的是消息永久丢失的窗口。简单重试不能完全替代它：系统若来不及确认发送结果，重试可能制造重复消息，下游还需按事件 ID 做幂等消费，避免重复扣库存或收费。
这次讨论担心闪购期间 Outbox 增加表写入、形成瓶颈，也提出失败提示或重试作为替代方案。但供稿只有架构取舍提问，没有吞吐测试或故障数据，因此无法判断这项额外写入是否真是瓶颈。可以确定的是，删掉 Outbox 并非单纯提速，而是接受“订单存在、事件消失”的风险。