補償トランザクション

すでにコミットした処理の効果を、逆向きの処理を実行して打ち消すトランザクション。複数のサービスやデータベースにまたがる処理を1つのトランザクションとしてロックできないときに、途中で失敗したら、完了済みの処理ごとに用意した補償トランザクション（予約の取消し、返金など）を実行して整合性を取る。Sagaパターンで使われる。

すでにコミットした処理の効果を、逆向きの処理を実行して打ち消すトランザクション。マイクロサービスのように複数のサービスやデータベースにまたがる業務処理は全体を1つのトランザクションでロックできないので、途中の処理が失敗したら、完了済みの処理ごとに用意した補償トランザクション（予約の取消し、返金など）を実行して整合性を取る（Sagaパターン）。完全に元の状態に戻るとは限らず、途中の状態をほかの処理が参照し得ることも考えて設計する。

老朽化・複雑化したレガシーシステムを、クラウド、マイクロサービス、コンテナなどの現代的な技術や設計に刷新すること。基盤の移し替えにとどまらず、アプリケーションの構造や開発・運用の方法も見直して、保守費用の削減、変化への対応の速さ、データの活用しやすさを高める。一度に全面刷新せず、段階的に置き換える方法が多くとられる。

分散トランザクションで、全サイトの更新をそろって確定させるためのプロトコル。第1相で調停者（コーディネータ）が各参加者にコミットの準備ができたかを問い合わせ、全員が「可」と答えた場合だけ第2相でコミットを、1つでも「否」や応答なしがあればロールバックを指示する。準備完了の後に調停者が故障すると、参加者は確定も取消しもできずに待たされる（ブロッキング）という弱点がある。

基本的に可用である（Basically Available）、状態は一時的に不定でよい（Soft state）、最終的に一貫する（Eventually consistent）という、分散データベースやNoSQLの設計の考え方。厳密な一貫性を求めるACID特性と対比され、更新直後の不一致を許す代わりに可用性とスケーラビリティを優先する。

複数のサイト（データベースやリソース）にまたがって更新を行うトランザクション。すべてのサイトで更新を確定するか、すべて取り消すかをそろえる必要があり、2相コミットメントなどのプロトコルで原子性を保証する。サイトの数が増えるほど待ちや障害の影響が大きくなるので、マイクロサービスでは補償トランザクションを使うSagaパターンで結果整合性をとることもある。

複数のサービスにまたがる処理の整合性を保つため、各サービスの処理をTry（資源の仮押さえと業務上の検査）、Confirm（仮押さえした内容の確定）、Cancel（仮押さえの取消し）の3つの操作に分けて実装する方式。調整役が全サービスにTryを依頼し、すべて成功したらConfirmを、1つでも失敗したらCancelを指示する。2相コミットメントに似た手順を業務処理として実現するもので、データベースのロックを長く持ち続けずに済む。

複数のサービスにまたがる長い業務処理を、サービスごとのローカルトランザクションの連続として実行し、途中で失敗したら、完了済みのローカルトランザクションを補償トランザクションで逆順に打ち消して整合性を取る方式。全体を1つのトランザクションでロックしないので、途中の状態が他の処理から見えることと、結果整合性になることを前提に設計する。各サービスがイベントで連携するコレオグラフィと、調整役が順に指示するオーケストレーションの2つの実装方法がある。