変更ログとしてMongoDBを使用する2つのシステム間の同期

2つの関連システムを開発しています。そのうちの1つ（A）は、お客様のマシンにインストールされます。残りの（B）は私の組織で使用されます。

各システムには独自のデータベース（リレーショナル）があり、スキーマは異なります。ただし、両方のシステムを同期する必要があります。さらに、Bの一部の変更はすべてのクラスAシステムにエクスポートする必要があり、その他は特定のシステムにのみエクスポートする必要があります。

一部のお客様はインターネットに接続していないため、場合によっては、ファイルの交換を介して同期を行う必要があります。

そのため、次のようにこの問題を解決する予定です。

1. 各システムは、データベースの変更ログを保持しています。MongoDBで実装する予定です。
2. システムが同期プロセスを初期化するとき、ログから行われたすべての変更を取得します。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。
3. 他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要な場合、システムは存在する可能性のある競合を解決する必要があります。
4. 最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。

このアプローチは実行可能で、スケーラブルでエレガントですか？どのような変更または追加を行いますか？

まだ行っていない場合は、イベント駆動型システム、イベントソーシング、および結果整合性について調べるのが面白いかもしれません。説明しているシステムには、これらのパターンと多くの類似点があります。これは良いことです。

特にあなたのアプローチは良さそうです：

• 順序付けされた変更ログの使用は、同期プロセスが最後に確認された変更以降に行われた変更のみを取得できることを意味します。これにより、処理時間が短縮され、スケーラビリティが向上し、インターネット接続が利用可能な場合にほぼリアルタイムの同期を構築できます。
• インターネットに接続していないお客様は、高速同期に頼って拡張性の問題をうっかり終了させるのではなく、遅延同期化と順序外れの同期化に対処することを考えざるを得ません。

ドメインモデルの詳細を知らなくても、競合を解決することが最も面倒な原因になると思います。私は、各種類の紛争がどのように解決されるかを考えるのに時間を費やすでしょう。特に：

• 一部の競合ではユーザーの解決が必要ですか？
• 顧客システムは、常に競合を解決するための正しい場所になるでしょうか？
• 顧客システムが変更を送信するステップ4の後、システムBで競合が発生する可能性はありますか？

各システムは、データベースの変更ログを保持しています。MongoDBで実装する予定です。

イベントストアを使用できます。そこでデータを更新すると、ストアに新しいイベントが作成されます。

システムが同期プロセスを初期化すると、ログから行われたすべての変更が取得されます。システムがBの場合、取得される変更は宛先によって異なります。次に、システムはそれらをXML形式でシリアル化し、最後に（ファイルまたはネットワーク経由で）送信します。

任意のメカニズムを使用してイベントを送信できますが、ファイルを処理する必要がない場合は、可能であればバスを使用する方が簡単です。通常、これらは、接続が送信可能になるまでメッセージを保持するように構成できます。

他のエンドポイントが変更セットを受信すると、それらのシリアル化を解除します。次に、システムはデータに対していくつかの変換を行います。これは必要な場合があり、最後に変更を記録します。このステップでは、必要な場合、システムは存在する可能性のある競合を解決する必要があります。

イベントをドメインオブジェクトに適用するだけです。

最後に、受信側システムはその変更（および競合解決の他の製品）を送信します。

同じアプローチを使用します。