Sincronização entre dois sistemas usando o MongoDB como changelog

Estamos desenvolvendo dois sistemas relacionados. Um deles (A) será instalado nas máquinas de nossos clientes. O restante (B) será usado pela minha organização.

Cada sistema possui seu próprio banco de dados (relacional) e seus esquemas diferem. No entanto, ambos os sistemas precisam ser sincronizados. Além disso, algumas alterações em B precisam ser exportadas para todos os sistemas de classe A e outras apenas para um sistema específico.

Alguns clientes não têm conexão com a Internet; portanto, a sincronização, em alguns casos, deve ser feita através da troca de arquivos.

Portanto, planejamos resolver esse problema da seguinte maneira:

1. Cada sistema mantém um registro de alterações do seu banco de dados. Estamos planejando implementá-lo com o MongoDB.
2. Quando um sistema inicializa um processo de sincronização, ele recupera todas as alterações feitas de um log. Se o sistema for B, as alterações recuperadas dependem do destino. Em seguida, o sistema os serializa no formato XML e, finalmente, os envia (via arquivo ou rede).
3. Quando o outro ponto de extremidade recebe o conjunto de alterações, ele os desserializa. Em seguida, o sistema faz algumas transformações nos dados, o que pode ser necessário e, finalmente, registra as alterações. Nesta etapa, se necessário, o sistema precisa resolver os conflitos que possam existir.
4. Por fim, o sistema receptor envia suas alterações (e outros produtos de resolução de conflitos).

Essa abordagem é viável, escalável e elegante? Que mudanças ou adições você faria?

Se você ainda não o fez, pode ser interessante ler sobre sistemas controlados por eventos, fornecimento de eventos e eventual consistência. O sistema que você está descrevendo tem muitos paralelos com esses padrões, o que é uma coisa boa.

Sua abordagem parece boa, em particular:

• O uso de um log de alterações ordenado significa que o processo de sincronização pode recuperar apenas as alterações feitas desde a última alteração vista. Isso manterá o tempo de processamento baixo, o que ajuda na escalabilidade e permite a criação de sincronização quase em tempo real nos casos em que a conectividade à Internet está disponível.
• Os clientes sem conexão com a Internet obriga a pensar em lidar com a sincronização atrasada e fora de serviço agora, em vez de confiar na sincronização rápida e acabar inadvertidamente com problemas de escalabilidade.

Sem saber mais sobre o modelo de domínio, meu palpite é que resolver conflitos é a parte que mais causará problemas. Eu passava algum tempo pensando em como cada tipo de conflito seria resolvido. Em particular:

• Alguns conflitos exigirão resolução do usuário?
• O sistema do cliente sempre será o local correto para resolver conflitos?
• É possível que haja conflitos no sistema B após a etapa 4, quando o sistema do cliente envia suas alterações?

Cada sistema mantém um registro de alterações do seu banco de dados. Estamos planejando implementá-lo com o MongoDB.

Você pode usar um eventstore . Qualquer atualização de dados criará um novo evento na loja.

Quando um sistema inicializa um processo de sincronização, ele recupera todas as alterações feitas do log. Se o sistema for B, as alterações recuperadas dependem do destino. Em seguida, o sistema os serializa no formato XML e, finalmente, os envia (via arquivo ou rede).

Você pode usar qualquer mecanismo para enviar eventos, mas seria mais fácil usar um barramento, se possível, onde você não precisa lidar com arquivos. Normalmente, eles podem ser configurados para reter mensagens até que a conectividade esteja disponível para enviá-la.

Quando o outro ponto de extremidade recebe o conjunto de alterações, ele os desserializa. Em seguida, o sistema faz algumas transformações nos dados, o que pode ser necessário e, finalmente, registra as alterações. Nesta etapa, se necessário, o sistema precisa resolver os conflitos que possam existir.

Simplesmente aplique os eventos aos objetos do seu domínio.

Por fim, o sistema receptor envia suas alterações (e outros produtos de resolução de conflitos).

Use a mesma abordagem.