Interactive
Sagaパターン可視化
注文作成→在庫引当→決済→配送手配という4つのローカルトランザクションが、コレオグラフィ型（サービス間で直接イベントをリレー）とオーケストレーション型（中央のオーケストレータが仲介）で それぞれどう進むかをシーケンス図で確認できます。正常系ではすべて即座にコミットして完了、 異常系では配送手配が失敗し、補償トランザクションが逆順（決済→在庫→注文）で実行されて収束する様子をステップごとに追えます。
中央の管理者を置かず、各サービスが直接イベントをリレーして4ステップ全て成功
前進（コミット/コマンド）応答失敗補償判定
1 / 4
ローカルTxコミット / 前進注文サービス → 在庫サービス
1. T1コミット →「注文作成」イベント発行
event: OrderCreatedorderId=9931注文サービスが注文レコードをローカルにコミットする。コミットした瞬間から他サービスにも可視になる（2PCのin-doubtは存在しない）。続けて「注文作成」イベントを発行し、在庫サービスがこれを購読して起動する。
ここが分かる
- 各ローカルトランザクションはコミットした瞬間に他から可視になる——2PCの「全員YESが揃うまで誰も確定できない」in-doubt状態はSagaには存在しない。ロックを長時間持たないからこそ、秒〜日単位の長い処理やサービス跨ぎでも成立する。
- 補償はUNDOではなく新しい正のトランザクション——「引当を解除する」「与信を解放する」という打ち消し操作として実行される。異常系で決済・在庫の補償ステップの説明文を読むと、この違いが具体的に分かる。
- コレオグラフィ型はサービス同士が直接イベントを購読し合う疎結合な方式、オーケストレーション型は中央のオーケストレータが手順と補償を一元管理する方式——同じ4ステップでも、失敗検知後に「次に何をすべきか」を判断する場所が分散しているか1か所に集約されているかが違う。
- 異常系では、失敗したステップ自身の補償は無い（何もコミットしていないため）。補償が要るのは、それより前に成功していた分だけを逆順にたどる——正常系と見比べると、どこまでが「前進」でどこからが「巻き戻し」かが視覚的に分かる。