背景
「サーガパターンの補償トランザクションみたいなものがデータメッシュにもあるのでは？」と思い、Geminiと壁打ちしていく中で得られた情報をログとして残します。
性質は違うが存在する
結論から述べると、存在する。
ただし、マイクロサービスのサーガパターンで見るような自動化されたワークフローとしての「補償トランザクション」とは少し性質が異なる。
データメッシュでは、補償の際に 「データプロダクトの再発行・修正版の提供」 という形を取ります。
これをちょっとした普段の日常の業務フローでアナロジーしてみましょう。
サーガの補償トランザクション
これは、銀行のATMで送金エラーが起きた際に、即座に自動で口座残高を元に戻すような、プログラム的な処理です。
データメッシュの「補償」
新聞社が、朝刊に誤った情報を掲載してしまったとします。
すでに配達された新聞（データプロダクト）から、その誤った情報をサクッと消すことはできません。
新聞社ができる「補償」は、翌日の朝刊とかに 「訂正記事」を掲載すること です。
つまり、「以前のデータは間違いでした。こちらが正しいデータです」と、
新しいバージョンの新聞やお知らせ（データプロダクト）を発行する
データメッシュにおける「補償」の仕組み
データメッシュにおいて、あるデータプロダクトに品質問題が発見された場合、
以下のようなプロセスが実行されます。
これが、データメッシュにおける補償トランザクションに相当します。
ちなみに、ここでのデータメッシュは、すでにデータプロダクトチームが
ドメインチームに吸収された後の組織構造を指します。
検知
データオブザーバビリティツールが、「昨日の売上データプロダクトにこんな異常がある」
ということを検知し、そのデータプロダクトのオーナーであるドメインチーム にアラートを通知します。
影響範囲の通知
オーナーチームは、データカタログなどを通じて、
そのデータプロダクトの 全ての消費者（下流のチーム） に対して、「昨日の売上データは現在信頼できません。利用を停止してください」と通知します。
「Data as a Product」の考え方
これは、「Data as a Product」というデータメッシュの基本原則に基づいています。
ソフトウェア開発において、あるライブラリにバグが見つかった場合、
開発元は特定のユーザーだけに修正版を送るのではなく、公式のパッケージリポジトリに新しいバージョンを公開します。
これと同じで、データプロダクトのオーナーは、修正版データを公式の場所（例: BigQueryのテーブル）に公開する責任を負います。
これにより、そのデータプロダクトを利用する全ての消費者（下流のチーム）が、一貫して同じ品質の正しいデータにアクセスできることが保証されます。
下流チームの一部にしか最新情報が届かないっていうんじゃ補償になってません。
原因究明と修正
オーナーチームは、データ品質問題の原因（例：データソースのバグ、パイプラインの不具合）を特定し、修正します。
修正版データの再発行
オーナーチームは、修正されたロジックでパイプラインを再実行し、正しいデータを持つ、新しいバージョンのデータプロダクトを発行します。
完了通知
オーナーチームは、消費者に「修正版のデータプロダクトが利用可能になりました。必要に応じて、下流のダッシュボードやレポートを更新してください」と通知します。
このように、データメッシュの「補償」は、自動化された技術的なロールバックというよりは、データのライフサイクル管理の一環として、オーナーチームが責任を持って行う、
よりプロセス指向の活動なのです。
ということは必然的に、業務プロセス改善の対象でもあるってことです✨