Non esiste un metodo o pattern standard per la sincronizzazione di più master (mutanti), quando non è possibile apportare modifiche al design a uno dei master (a meno che non si abbia già tutte le funzionalità che si desidera).
Devi essere in grado di rilevare le modifiche dall'ultima volta che hai controllato. La differenza di massa è fuori perché è possibile farlo solo una volta al giorno, in più probabilmente sarebbe comunque inutilizzabile per il rilevamento dei cambiamenti in tempo reale.
Ciò significa utilizzare uno schema di numerazione delle versioni e questa è una modifica allo schema principale e all'approccio alla modifica dei dati, poiché lo schema dei numeri di versione richiede manutenzione durante gli aggiornamenti.
Idealmente, riceverai una notifica push sulle modifiche al master, ma stai dicendo che è fuori discussione.
Ancora, vuoi una sincronizzazione bidirezionale in tempo reale. Quindi, quello che stai cercando è noto come magic e non esiste.
Ora, se non hai il controllo sui client, allora è game over.
Quindi, supponendo che tu abbia un certo controllo sul client, dovrai modificare la dichiarazione del problema & requisiti per qualcosa di gestibile. Con i tuoi vincoli di sistema, non c'è modo di tenere tutto sincronizzato quasi in tempo reale.
Tuttavia, un client potrebbe essere in grado di estrarre una piccola quantità di dati dal server prima di apportare una modifica. Quindi, il client non è sincronizzato al 100%, ma ha abbastanza per apportare alcune modifiche minori ma accurate.
Inoltre, il cliente dovrebbe considerare queste modifiche come provvisorie fino a quando non vengono replicate e confermate dal server.
Ciò si traduce in un'esperienza utente client diversa rispetto all'utilizzo di un unico master store centralizzato (che è ciò che si sta tentando di emulare grazie alla sincronizzazione in tempo reale con più master).
Non c'è modo di nascondere che le modifiche sono provvisorie fino alla conferma e che alcune modifiche che hanno conflitti dovranno essere ripristinate e / o rifatte in seguito. Quindi, l'esperienza dell'utente non ha altra scelta che quella di affrontarlo.