Orchestration 更适合强一致性、可追踪、易调试场景，需 SagaCoordinator 状态机协调；Choreography 适合松散事件驱动协作，但须本地落库+幂等补偿。二者选型取决于失败传播责任边界。
Go 里 Saga 模式该用 Orchestration 还是 Choreography？看失败恢复路径
Orchestration 更适合需要强一致性、可追踪、易调试的业务流程；Choreography 更适合高内聚、低耦合、事件驱动的松散服务协作。选错会导致补偿逻辑失控或事务链路不可观测。
orchestration 的核心：必须有一个中央协调器 SagaCoordinator
它不是“调度器”，而是状态机 + 补偿指令分发器。没有它，Compensate() 就会变成无头苍蝇。
-
SagaCoordinator必须持久化每一步执行状态（比如用pgx存saga_id、step、status），否则重试时不知道该从哪补 - 每个子服务只和协调器通信，不感知其他服务——这是避免循环依赖的关键
- 推荐用
go.temporal.io/sdk而非手写：它的ExecuteActivity+ContinueAsNew天然支持断点续跑，手写容易漏掉幂等或超时重试
choreography 的陷阱：事件丢失 ≠ 事务失败，但开发者常当成一回事
用 github.com/segmentio/kafka-go 或 redis streams 发布事件时，90% 的问题出在“以为发出去就成功了”。
- 发布事件前必须先本地落库（比如写入
saga_events表，status = 'pending'），再异步投递；投递成功后才更新为'published' - 消费者必须实现至少一次语义（
AtLeastOnce），且Compensate()本身要幂等——因为同一条事件可能被消费两次 - 没有全局
saga_id关联所有事件？查故障时你会在日志里找不到上下游关系
性能与可观测性差异：Orchestration 写多读少，Choreography 读多写少
Orchestration 的瓶颈在协调器单点写入（如 PostgreSQL update），Choreography 的瓶颈在事件广播延迟和消费者堆积。
立即学习“go语言免费学习笔记（深入）”；
- Orchestration 下，
GetSagaState(ctx, sagaID)是高频查询，建议加 Redis 缓存，但注意缓存与 DB 状态一致（用Cache-Aside+ 延迟双删） - Choreography 下，每个服务都要监听多个 topic/stream，别把所有 saga 事件塞进一个
order-eventstopic——按业务域拆分，否则消费者无法独立扩缩容 - 两者都必须打结构化日志：至少含
saga_id、step_name、attempt、error，否则jaeger链路里看不到补偿跳转
最常被忽略的是：Saga 不是银弹。跨数据库、跨网络、跨团队的服务，用 Choreography 很难对齐补偿语义；而纯内部微服务链路，硬套 Orchestration 又会把简单流程搞重。关键不在模式本身，而在谁承担失败传播成本——这个责任边界，代码写不出来，得靠上下游一起签清楚。
