Saga パターン

複数のサービス・集約をまたぐ長期トランザクションを、独立した小さなステップと補償アクションで構成し、結果整合性を保つ設計パターン。1987 年に Hector Garcia-Molina と Kenneth Salem が DB 理論として提唱し、後にマイクロサービスアーキテクチャの分散トランザクション解として再注目された。

なぜ Saga が必要か

サービス境界（あるいは集約境界）を跨ぐ業務では、2 フェーズコミット（2PC）はパフォーマンス・可用性の点で現実的でない。Saga は 「ローカルトランザクションの連鎖 + 失敗時の補償」 で結果整合性を実現する。

構造

Step 1: 注文受付      → 成功 → イベント発行
Step 2: 在庫引当      → 成功 → イベント発行
Step 3: 決済処理      → 失敗
  ↓
補償: 在庫引当キャンセル
補償: 注文取消

2 つのスタイル

スタイル	制御	特徴
Choreography（振付）	各サービスがイベントを購読して自律的に動く	疎結合・関係数が少ない場合に向く
Orchestration（指揮）	中央の Saga マネージャが順序とリトライを制御	フローが複雑・補償が多い場合に向く

補償トランザクションが核心

通常の DB ロールバックと違い、Saga の「巻き戻し」は 業務イベントで表現する。

順方向	補償
在庫引当	在庫引当キャンセル
決済承認	決済返金
注文確定	注文取消
メール送信	お詫びメール送信（送信は取り消せない）

「物理的に取り消せないアクション」（メール送信・物流連携）は、補償ではなく 後続の通知や謝罪フロー で対処する設計が現実解。

Saga が効く場面

マイクロサービス間で長期トランザクションが必要
業務上「失敗」が日常的に起こる（在庫切れ・決済失敗・配送不可）
複数チャネル（モール・店頭・倉庫）の状態同期
監査要件が厳しく、補償の経緯まで残したい

Saga が過剰な場面

単一 DB で完結する CRUD 主体の業務
強整合性を業務側が要求する領域（金融トレード当日決済など）
チームに分散システム運用の知見が薄い段階

アンチパターン

失敗	何が起きるか
補償を後回しに設計	失敗が日常的に発生して人手で巻き戻す羽目に
Saga 内に同期 RPC を多用	結局 2PC と同じ可用性問題が発生
「ゾンビ Saga」放置	中間状態のまま停止した Saga が残り続ける
Choreography で 10 サービス連携	イベントの因果関係が追えなくなる

開発手法ガイド：概要 — DDD 発展形としての位置づけ
CTS-EC 共通商品マスタ — マルチモール在庫同期で Saga が活きる典型ドメイン