分散トランザクション

複数のサービスにまたがる1回の書き込み操作——グローバルなACIDは存在しない。2PCは強い整合性を追求するが、コーディネーターが障害発生すると参加者がすべてブロックされる。SagaやTCCは補償トランザクションで可用性と引き換えに、アプリケーション層でロールバックロジックを自前で実装する必要がある。outbox patternと冪等性により、実装上の「少なくとも1回」の配信が保証される。

単一ノードのデータベースではトランザクションはACID準拠であり、BEGIN/COMMIT/ROLLBACKで制御できる。しかし分散システムでは複数のサービスが関与するため、グローバルなACIDトランザクションは存在しない。

2PC (Two-Phase Commit)

最も基本的な分散トランザクションプロトコル——ブロッキング型であり、コーディネーターの障害に対する耐性を持たない。

問題点: coordinatorがPREPARE後、COMMIT前にクラッシュした場合 → participantは不確実な状態(uncertain state)に陥る——他のparticipantがYESかどうか分からないため単独でコミットできず、他がすでにコミットしている可能性もあるため単独でアボートもできない。⁠参加者がブロックされ、coordinatorの回復を待つ——これが「ブロッキングプロトコル」である。

実務では: XAトランザクション（2PCの実装）はデータベースのシャーディング間トランザクションで使われるが、coordinatorのクラッシュへの対応には管理者によるヒューリスティックなコミット/アボートが必要になる。

Saga

長時間のトランザクションを複数のローカルトランザクションステップに分割し、各ステップには独自の補償操作(compensating action)を持たせる。あるステップで失敗した場合、完了したステップを逆順で補償実行する。

Sagaには分離性がない（他のトランザクションが中間状態を見ることができる）が、ブロックしない——いつでもシステムは進行中(progressing)である。

オーケストレーションモード

• Choreography: 各サービスが前のステップのイベントを消費し、自身の完了/失敗イベントを公開する——中央のオーケストレーターは存在しない
• Orchestration: 中央のSagaコーディネーターが各サービスに「ステップを実行」または「補償を実行」を指示する——ロジックが集中しており、管理が容易

TCC (Try-Confirm-Cancel)

Sagaのバリエーションで、より「厳格な」リソース予約に適している。

Try:     リソースを予約 (在庫確認、残高凍結) — リソースは**消費されていない**、単に「使用待ち」マーク
Confirm: リソースを実際に消費 (在庫減算、入金処理)
Cancel:  予約を解放 (在庫解放、残高解除)

Sagaとの違い: Sagaのステップはデータを直接変更する（book_flightは実際にチケットを予約する）、補償はundoである。TCCのTryは予約のみを行い、Confirmが実際に変更を行う——⁠いつでもCancelでき、後でundoを実行する必要がない⁠。

冪等性

分散システムにおいて最も重要な非機能的要件: f(x) = f(f(x))——再試行操作が結果に影響を与えない。

実装方法:
  1. unique idempotency key: クライアントがUUIDを生成し、サーバーが保存 ((key) → (処理済み/未処理))
     → 重複するkey → キャッシュされた結果を返す、再実行しない
  2. database constraints: INSERT INTO orders VALUES (order_id=123, ...)
     → 再試行 → UNIQUE制約違反 → 無視または既存レコードを読み取る
  3. token-based: サーバーがクライアントにトークンを発行し、クライアントがリクエストにトークンを付与
     → 重複するtoken → 拒否

冪等でない例:
  UPDATE users SET balance = balance + 100  -- 再試行 = 2回加算される!
  修正: UPDATE users SET balance = ? WHERE version = ? (楽観的ロック)

Outbox Pattern

トランザクションとしてデータベースに書き込み + メッセージキューにメッセージを送信——両者を原子性で保証するには？DBに書き込んでからメッセージを送信するのは不可（DB書き込みは成功したがメッセージ送信が失敗 → 不整合）。

[ローカルトランザクション]:
  INSERT INTO orders (...);
  INSERT INTO outbox (event_type, payload, created_at) VALUES ('order_created', '...', NOW());
  COMMIT;  ← 両方が同じローカルトランザクション内にある!

[Outbox Poller]:
  SELECT * FROM outbox ORDER BY id → Kafka/MQに送信 → 成功 → outboxから削除

保証: orderの書き込み + eventの生成は原子性（同じトランザクション内）。Outbox pollerがat-least-once配信を行う。

参考

• 論文⁠: "Sagas" (Garcia-Molina & Salem, 1987)
• マイクロサービストランザクション⁠: microservices.io/patterns/data/saga.html
• 冪等性⁠: stripe.com/docs/idempotency (本番環境レベルの実装)

Keywords: 2PC, XA, Saga, TCC, compensating action, idempotency, outbox pattern, distributed transaction