Sagaパターン

ビジネスプロセス: 注文作成 → 在庫確保 → 決済 → 配送手配（4サービス）

オーケストレーション方式で実装:

• OrderSagaOrchestratorが各サービスを順次呼び出す
• 各ステップの状態をPostgreSQLに永続化

障害シナリオ: 決済サービスがタイムアウト

1. オーケストレーターが3回リトライ（指数バックオフ）
2. 3回失敗 → 補償フロー開始
3. C2: 在庫サービスに「在庫戻し」リクエスト → 成功
4. C1: 注文を「キャンセル」ステータスに更新 → 成功
5. ユーザーに「決済に失敗しました」と通知

結果: 月間15万件の注文を処理し、障害発生率0.3%の状況でもデータ不整合ゼロを達成。補償アクションの平均完了時間は2.1秒。

ビジネスプロセス: フライト予約 → ホテル予約 → レンタカー予約

コレオグラフィ方式で実装:

• 各サービスがKafkaにイベントを発行し、次のサービスが購読
• FlightBooked → HotelBooked → CarBookedの連鎖

障害シナリオ: レンタカー予約が在庫切れで失敗

1. レンタカーサービスがCarBookingFailedイベントを発行
2. ホテルサービスが購読し、ホテル予約をキャンセル → HotelCancelled発行
3. フライトサービスが購読し、フライト予約をキャンセル

結果: 1日3,200件の予約処理で、全キャンセルの整合性を保証。ただし、サービスが5つに増えた時点でイベントの流れが追いにくくなり、オーケストレーション方式に移行した。

ビジネスプロセス: 残高チェック → 送金元引落 → 送金先入金 → 通知

課題: オーケストレーターがステップ2完了後にクラッシュ。再起動後に「どこまで進んだか」がわからず、二重引落のリスク。

対策:

• サガの各ステップをDBに記録（saga_id, step, status, created_at）
• オーケストレーター再起動時に未完了のサガをDBから復元
• 各ステップに冪等性キーを付与し、リトライ時の二重実行を防止

結果: 月間8万件の送金を処理。オーケストレーターの計画的再起動を含め、二重引落・二重入金は累計ゼロ。サガの状態テーブルが障害調査のログとしても機能し、原因特定時間が平均45分→8分に短縮。