订单、库存和支付拆开后，过去一个本地事务能覆盖的动作可能跨越多个系统。此时最重要的不是寻找一个“永不失败”的组件，而是为部分成功定义可识别、可恢复的业务状态。
先写出所有中间状态
假设库存已经预留、付款尚未确认，系统应该显示处理中、允许取消还是继续等待？这些规则应由业务负责人确认。用状态表记录允许的转换、触发条件和超时后的责任，比直接从代码里拼一个长流程更容易审查。
补偿不等于时间倒流
退回库存、取消预订和退款都是新的业务动作，可能再次失败，也可能受外部规则限制。每一步都要有幂等标识、执行记录和可重试条件。已经发出的通知或已完成的外部交付，未必存在完全逆向的操作。
选择谁掌握流程进度
可以评估由一个流程协调者记录步骤，或由事件推动各方协作。前者更容易集中查看状态，后者需要避免依赖关系隐蔽。选择时看流程长度、责任边界和排查能力，不要把某种模式当成所有交易的统一答案。
验收一笔卡住的业务
故意让一个步骤成功后响应丢失，再让补偿暂时失败，检查系统是否仍能找到该业务、区分状态并安全恢复。交付必须包括对账和人工处理入口，不能只展示正常订单跑通。
常见问题：Saga 能替代所有数据库事务吗？
不能。服务内部仍可使用适合业务边界的本地事务。Saga 讨论的是跨步骤协作与补偿，复杂度需要与业务收益一起评估。
技术参考：微软：Saga 模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果内部团队需要把这些约定落到可运行的工程中，可以通过微服务基础架构建设沟通接口、公共能力与交接范围，先以一个业务场景验证方案。