データベースCDCを使用したイベントソーシングは優れたアーキテクチャと見なされますか？
ソースイベントについて説明するとき、データベースに書き込むことができるシンプルなデュアル書き込みアーキテクチャがあり、Kafkaのようなキューにイベントを書き込むことができます。他のダウンストリームシステムはこれらのイベントを読み取り、それに応じて行動/使用してください。
しかし、DBとイベントの両方を同期させようとすると、これらのイベントの順序付けが意味をなすために必要になるため、問題が発生します。
これらの問題を解決するために、データベースコミットログをイベントのソースとして使用することを奨励している人がいます。AirbnbのSpinal Tap、RedhatのDebezium、Oracleのゴールデンゲートなどのツールを使用して構築されています。これにより、一貫性の問題、保証の注文、およびこれらすべての問題が解決されます。 。
ただし、データベースコミットログをイベントソースとして使用する場合の問題は、DBスキーマと密接に結合していることです。マイクロサービスのDBスキーマが公開され、データ型の変更や列名の変更など、DBスキーマの重大な変更が実際にダウンストリームシステムを破壊する可能性があります。
イベントソースとしてDB CDCを使用するのは良い考えですか？
ただし、データベースコミットログをイベントソースとして使用する場合の問題は、DBスキーマと密接に結合していることです。マイクロサービスのDBスキーマが公開され、データ型の変更や列名の変更など、DBスキーマの重大な変更が実際にダウンストリームシステムを破壊する可能性があります。
それはそうです。ただし、ではないイベントソーシングの際にデータを共有するときに直面する問題と何ら変わりはありません。
つまり、生産者と消費者は両者の契約について合意する必要があります。また、契約を長期的に実行可能にする場合は、その設計に投資して、契約が実装の不安定な部分から切り離されるようにする必要があります。
これはRDBMSの場合もありますが、コンシューマを特定のテーブルスキーマに結合する代わりに、ビューまたはストアドプロシージャへのアクセスを許可します。または、Webエンドポイントまたはドキュメントストアを作成して、コンシューマーにそれを読み取らせることもできます。