Sincronización entre dos sistemas usando MongoDB como registro de cambios

Estamos desarrollando dos sistemas relacionados. Uno de ellos (A) se instalará en las máquinas de nuestros clientes. El resto (B) será utilizado por mi organización.

Cada sistema tiene su propia base de datos (relacional) y sus esquemas difieren. Sin embargo, ambos sistemas tienen que estar sincronizados. Además, algunos cambios en B deben exportarse a todos los sistemas de clase A y otros solo a uno específico.

Algunos clientes no tienen conexión a Internet, por lo que la sincronización, en algunos casos, debe realizarse mediante el intercambio de archivos.

Entonces, estamos planeando resolver este problema de la siguiente manera:

1. Cada sistema mantiene un registro de cambios de su base de datos. Estamos planeando implementarlo con MongoDB.
2. Cuando un sistema inicializa un proceso de sincronización, recupera todos los cambios realizados desde un registro. Si el sistema es B, los cambios recuperados dependen del destino. Luego, el sistema los serializa en formato XML y, finalmente, los envía (a través de un archivo o una red).
3. Cuando el otro punto final recibe el conjunto de cambios, los deserializa. Luego, el sistema realiza algunas transformaciones sobre los datos, que pueden ser necesarias, y finalmente, registra los cambios. En este paso, si es necesario, el sistema tiene que resolver los conflictos que puedan existir.
4. Por último, el sistema receptor envía sus cambios (y otros productos de resolución de conflictos).

¿Es este enfoque factible, escalable y elegante? ¿Qué cambios o adiciones harías?

Si aún no lo ha hecho, puede que le resulte interesante leer sobre sistemas controlados por eventos, fuente de eventos y consistencia eventual. El sistema que está describiendo tiene muchos paralelos con estos patrones, lo cual es algo bueno.

Su enfoque suena bien, en particular:

• El uso de un registro de cambios ordenado significa que el proceso de sincronización puede recuperar solo los cambios realizados desde el último cambio visto. Esto mantendrá el tiempo de procesamiento bajo, lo que ayuda a la escalabilidad y le permitirá construir una sincronización casi en tiempo real en los casos en que la conectividad a Internet esté disponible.
• Los clientes sin conexión a Internet lo obligan a pensar en lidiar con la sincronización retrasada y fuera de orden ahora, en lugar de depender de una sincronización rápida y terminar inadvertidamente con problemas de escalabilidad.

Sin saber más sobre el modelo de dominio, supongo que resolver conflictos es la parte que le causará más problemas. Pasaría un tiempo pensando en cómo se resolvería cada tipo de conflicto. En particular:

• ¿Algunos conflictos requerirán resolución del usuario?
• ¿El sistema de clientes siempre será el lugar correcto para resolver conflictos?
• ¿Es posible que haya conflictos en el sistema B después del paso 4 cuando el sistema del cliente envía sus cambios?

Cada sistema mantiene un registro de cambios de su base de datos. Estamos planeando implementarlo con MongoDB.

Puedes usar un almacén de eventos . Cualquier actualización de datos creará un nuevo evento en la tienda.

Cuando un sistema inicializa un proceso de sincronización, recupera todos los cambios realizados del registro. Si el sistema es B, los cambios recuperados dependen del destino. Luego, el sistema los serializa en formato XML y, finalmente, los envía (a través de un archivo o una red).

Puede usar cualquier mecanismo para enviar eventos, pero sería más fácil usar un bus si es posible donde no tiene que lidiar con archivos. Por lo general, estos pueden configurarse para retener mensajes hasta que haya conectividad disponible para enviarlo.

Cuando el otro punto final recibe el conjunto de cambios, los deserializa. Luego, el sistema realiza algunas transformaciones sobre los datos, que pueden ser necesarias, y finalmente, registra los cambios. En este paso, si es necesario, el sistema tiene que resolver los conflictos que puedan existir.

Simplemente aplique los eventos a sus objetos de dominio.

Por último, el sistema receptor envía sus cambios (y otros productos de resolución de conflictos).

Usa el mismo enfoque.