メカニズムの詳細 (イベント駆動)
データメッシュにおけるデータプロダクト間の連携は、
まさに、Sagaパターン（特にコレオグラフィ型サーガ）のアナロジーが完璧に当てはまる、イベント駆動アーキテクチャのメカニズムです。
この流れは、まさに、アンソロジーサーガのメカニズムと一緒。
今回は簡単のために、データプロダクトABからのみで構成されたデータメッシュとします。
1. データプロダクトA (生産者)
自身のドメイン（例：注文）でビジネス上の「事実」が発生すると（例：OrderPlaced）、その事実を表すドメインイベントを1回発行します。
2. メッセージブローカー (メッシュ基盤)
イベントバス（Kafka, Pub/Subなど）が、そのイベントを受け取り、永続化します。
3. データプロダクトB (消費者)
OrderPlacedイベントを 購読（Subscribe） しています。
4. データプロダクトB (消費者)
ブローカーからイベントを能動的に受信し、それをトリガーとして自身のデータ（例：配送）の状態を変更します。
サーガパターンとの完璧なアナロジー
構造自体は、非同期で結果整合、コレオグラフィ型のサーガである、アンソロジーサーガ
まったくもって一緒です。
コレオグラフィ型サーガ
これは、中央の指揮者（オーケストレーター）がいないサーガです。
各サービスは、他のサービスが発行する「イベント」を聞き、そのイベントをトリガーとして、自律的に「次に何をすべきか」を判断して動きます。
オーケストレーション型のサーガとの違いは、イベントを発行する側は、
「私たちは、自分たちのなすべきことを契約通りやってイベントを発行したんだから、あとは、そっちで何とかやってくださいね。」
というものです。
データメッシュ
これは、中央のETLチーム（オーケストレーター）がいないデータアーキテクチャです。
各データプロダクト（A）は、自身の「イベント」を発行するだけです。
他のデータプロダクト（B）は、そのイベントを聞き、自律的に「自身のデータをどう更新すべきか」を判断して動きます。
結論
データメッシュは、データの世界にコレオグラフィ型サーガの原則を適用したものです。
これにより、データプロダクト（A）は、自身のイベントが誰（B）によって、どのように使われるかを一切知る必要がなくなり（＝疎結合）、アーキテクチャ全体の拡張性とアジリティが劇的に向上するようになります。