Saga
分散システムにおいて分散トランザクションを使わずに一貫性を保つための設計パターン
1つのトランザクションを、各サービスごとに小さなLocal Transactionに分割して連携させる
失敗時はCompensating Transactionで巻き戻すことが可能
2方式ある
Choreography方式のSaga
Orchestration方式のSaga
#WIP
基本構造
Saga：一連の処理の流れ
Local Transaction：各サービス内で完結するDBトランザクション
Compensating Transaction：途中で失敗した場合に、すでに完了した処理を打ち消す処理
rollcackにはCompensating Transactionを使用する
各transactionに対して、Compensating Transactionを定義する
失敗時にはこれを実行してデータの一貫性を保つ
gpt-5.icon
https://microservices.io/i/sagas/Create_Order_Saga_Orchestration.png
具体例（注文処理）
1. 注文作成（Order Service）
2. 在庫確保（Inventory Service）
3. 支払い処理（Payment Service）
失敗例
支払いが失敗
→ 在庫確保をキャンセル（補償）
→ 注文をキャンセル（補償）
Saga Patternを使う理由
2PC（Two-Phase Commit）が使えない／使いたくない
マイクロサービスでDBを共有していない
可用性・スケーラビリティを重視したい
注意点・落とし穴
完全なACIDは保証しない（最終的整合性）
補償トランザクションは「元に戻す」ではなく「打ち消す」
冪等性（同じ処理を複数回実行しても安全）が必須
途中状態を前提にしたUX設計が必要
どちらを選ぶべきか（目安）
小〜中規模、イベント駆動が中心 → Choreography
複雑な業務フロー、明確な制御が必要 → Orchestration
https://microservices.io/patterns/data/saga.html
https://qiita.com/yasuabe2613/items/b0c92ab8c45d80318420
Optimistic Offline Lock
https://martinfowler.com/eaaCatalog/optimisticOfflineLock.html
『マイクロサービスパターン 実践的システムデザインのためのコード解説』に詳しく書かれているらしい
4章は、まるまるSagaの章だけど、Sagaの必要条件である、5章のルール3は絶対読んで欲しい。ref