Funzionalità di elaborazione delle transazioni di dati offline in un contesto di scarsa connettività Internet

How to design the architecture for this and ensure that there is no transactional issues at any given point of time, and at the same time the centralized database contains the latest data from all branches ?

In breve: per i problemi di connettività di rete gravi tra filiali, è non possibile avere una soluzione in tempo reale .

Tuttavia, in quanto soluzione di compromesso, si può avere un "processo di sincronizzazione dei dati" notturno sul database / repository centrale quando la connettività di rete è stabile. Lo svantaggio sarebbe avere informazioni di un giorno nel database centrale. Questa è ancora una buona soluzione per scopi di reporting , tuttavia, per la soluzione transactionl in tempo reale non sarebbe sufficiente.

Come ulteriore spunto di riflessione, puoi prendere in considerazione approccio di accodamento distribuito , in quanto accumulerà le richieste al server centrale principale mentre la connettività è persa o instabile. Una volta che la connettività di rete si alza, li invierà in un ordine.

Nel complesso, ciò richiede un trade-off , piuttosto che una soluzione in tempo reale funzionante per sistemi con problemi di connettività.

Oltre a progettare magari un processo di sincronizzazione durante la notte, un'altra opzione potrebbe essere l'utilizzo di un approccio di accodamento distribuito. In altre parole, una coda nel sito di succursale può accodare richieste quando la connettività è inattiva e queste possono essere rimosse dal sistema di ricezione quando la connettività è attiva. Questo articolo offre una buona panoramica. Esistono numerosi prodotti / progetti che supportano questa funzionalità: alcune possibilità includono Apache ActiveMQ , RabbitMQ e MSMQ . In questo caso, MSMQ è probabilmente il più rilevante.

Da un punto di vista dell'applicazione front-end, è necessario progettare per questo tipo di operazione asincrona. Cioè, la transazione deve essere considerata completa dall'applicazione quando viene posizionata sulla coda e l'ipotesi è che la coda sia completamente affidabile.

Per quanto riguarda la posizione centrale, disporrà sempre delle ultime informazioni disponibili in base alla disponibilità della rete, soggetto a qualsiasi ritardo introdotto dal tempo necessario per elaborare le richieste in coda. Questo è il meglio che puoi fare in termini di recency delle informazioni se la rete non è affidabile.

Questo tipo di accodamento asincrono può essere utile per una serie di ragioni che vanno al di là della connettività di rete ed è uno schema utile da conoscere. Ad esempio, può essere utilizzato per semplificare in modo efficace il carico per un sistema che gestisce il lavoro da più richiedenti che non richiedono una risposta immediata. Il "server" in questo caso non ha bisogno di essere in grado di gestire tutto il carico al suo interno in modo da poter essere più efficiente da un utilizzo delle risorse e non da server specifici per gestire i carichi "di picco", rimanendo per lo più inattivi.

Non so se soddisfiamo le tue esigenze per le transazioni in tempo reale, ma potresti voler utilizzare la replica di SQL Server.

Potresti avere un server Web e SQL Server in esecuzione nella tua postazione remota. Gli utenti lì si collegherebbero a quell'istanza. Utilizzando Replication, SQL Server manterrà i tuoi dati sincronizzati tra le due posizioni. Se si verificava un calo della connessione, SQL Server gestiva la riconciliazione dei dati quando la connessione era nuovamente disponibile.

Non posso garantire che questa sia la soluzione migliore per te senza conoscere tutti i tuoi requisiti o il tuo accesso alle licenze di SQL Server. Ma è qualcosa che potresti voler investigare.

Se soddisfa le tue esigenze, sarebbe una soluzione che non richiederebbe ulteriori sviluppi.