Sync Engine: concetti chiave, tipi e meccanismi di funzionamento

Cos’è un motore di sincronizzazione?

Sync Engine — è un livello architetturale tra il database locale e un’API remota che gestisce il flusso di dati in entrambe le direzioni. I suoi compiti: tracciare le modifiche, inviarle al server, ricevere le modifiche dal server e risolvere i conflitti. L’utente interagisce con i dati locali, mentre Sync Engine li sincronizza perfettamente con il server.

Sync Engine può essere integrato (Firebase Firestore, Couchbase Lite, Realm) o personalizzato — scritto per una logica di business specifica. I motori integrati offrono funzionalità offline-first e risoluzione dei conflitti pronte all’uso. I motori personalizzati offrono il controllo completo sul formato dei dati, il protocollo di sincronizzazione e la politica dei conflitti.

Secondo Sravana Karthik (2024), autore di «Mobile Sync Engine Design Patterns», un Sync Engine personalizzato è giustificato per app con logica di business complessa (finanza, sanità, IoT) dove le regole di merge personalizzate sono critiche. Per scenari tipici (note, chat, feed), un Firestore o Realm integrato è sufficiente.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

Questa interfaccia descrive il contratto minimo di Sync Engine: pull (caricare le modifiche dal server), push (inviare modifiche locali), resolve (gestire i conflitti) e observe (monitorare lo stato di sincronizzazione). Questa astrazione consente di cambiare l’implementazione senza modificare il livello di presentazione.

Tipi di sincronizzazione: completa, incrementale e push

Sincronizzazione completa (Full sync) — ogni sessione carica l’intero set di dati dal server. Semplice da implementare, ma inaccettabile per volumi elevati: scaricare 10.000 record ogni volta che si apre l’app consuma traffico e batteria. La sincronizzazione completa è giustificata per dati di riferimento (elenco paesi) con aggiornamenti rari.

Sincronizzazione incrementale — vengono trasferiti solo i record modificati dall’ultima sincronizzazione. Il server memorizza il timestamp dell’ultima modifica per ogni record o per l’intero set. Il client invia lastSyncTimestamp e riceve solo i record con updated_at > quel valore. Secondo Instagram Engineering (2024), la sincronizzazione incrementale riduce il volume di dati trasferiti del 97% rispetto alla sincronizzazione completa.

Sincronizzazione push (avviata dal server) — il server stesso notifica al client la necessità di sincronizzare tramite FCM (Firebase Cloud Messaging), WebSocket o SSE (Server-Sent Events). Il client non spreca risorse in polling periodico. La sincronizzazione push è la scelta ottimale per app in tempo reale: chat, notifiche, like. Google Firebase Firestore utilizza WebSocket per la sincronizzazione in tempo reale con fallback automatico su HTTP polling.

Approccio ibrido — una combinazione di tipi: sincronizzazione completa per i dati di base all’avvio dell’app, poi sincronizzazione incrementale per gli aggiornamenti e, per eventi critici, sincronizzazione push tramite FCM. Questo offre sia velocità che risparmio di risorse.

Sincronizzazione incrementale — come funzionano checkpoint e delta

Checkpoint — un valore che il client memorizza tra le sessioni di sincronizzazione. Di solito è l’updated_at dell’ultimo record sincronizzato con successo. Alla sincronizzazione successiva, il client invia il checkpoint al server e il server restituisce tutti i record con updated_at successivo al checkpoint. Paginazione basata su cursore — una versione avanzata in cui il server restituisce un cursore (puntatore alla pagina successiva) insieme ai dati.

Sincronizzazione delta — il server calcola la differenza tra lo stato corrente dei dati e lo snapshot che il client ha visto l’ultima volta. Invece di inviare tutti i record, vengono trasferite solo le operazioni (insert, update, delete). Ciò è particolarmente efficace per set di dati grandi in cui solo pochi record sono cambiati. API Google Drive (2025) utilizza changes.list con pageToken per la sincronizzazione delta dei file.

Strategia dei «deltas differiti» — sul client mobile, le modifiche non vengono inviate immediatamente ma vengono bufferizzate nella coda offline. Quando viene raggiunta la soglia (10 operazioni o 30 secondi), viene formato un pacchetto delta e inviato al server. Secondo Dropbox Mobile Engineering (2024), il raggruppamento dei delta ha ridotto il numero di richieste HTTP del 65% e il consumo della batteria del 12%.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint memorizza sia il timestamp che il cursore di paginazione per elenchi lunghi. Checkpoint a due parametri garantisce che nessun record venga saltato o duplicato durante la sincronizzazione di grandi set di dati.

Sincronizzazione push — sincronizzazione istantanea tramite WebSocket e FCM

WebSocket — una connessione bidirezionale persistente tra client e server. Il server invia gli aggiornamenti immediatamente quando i dati cambiano. WebSocket è ottimale per app in tempo reale: chat, streaming, lavoro collaborativo. Svantaggio: consumo di batteria e traffico per mantenere la connessione (heartbeat). OkHttp WebSocket su Android e URLSessionWebSocketTask su iOS — implementazioni integrate.

Firebase Cloud Messaging (FCM) — notifiche push che il server invia non per la visualizzazione all’utente ma per attivare la sincronizzazione. Al ricevimento di un silent push (messaggio di dati), l’app si riattiva e avvia Sync Engine. FCM non richiede una connessione permanente ed è più economico di WebSocket per notifiche rare.

SSE (Server-Sent Events) — un canale unidirezionale attraverso il quale il server invia eventi al client. Più semplice da implementare di WebSocket, ma non supporta la comunicazione bidirezionale. EventSource API (JavaScript) e OkHttp SSE (Android) — librerie popolari. SSE è adatto per notifiche su nuovi dati quando il client non deve inviare dati indietro attraverso lo stesso canale.

Secondo WhatsApp Engineering (2024), il loro Sync Engine utilizza una combinazione di WebSocket per sessioni attive e FCM per riattivare l’app in background: WebSocket si disconnette dopo 5 minuti di inattività e gli aggiornamenti successivi vengono consegnati tramite silent push.

Sincronizzazione snapshot e versionamento dei dati

Sincronizzazione basata su snapshot — il server crea periodicamente uno snapshot completo dei dati e gli assegna una versione. Il client memorizza il numero di versione corrente. Se è obsoleto — scarica un nuovo snapshot. Questa è una strategia semplice e affidabile, ma inefficiente per cambiamenti frequenti — ogni volta viene scaricato l’intero set di dati.

Versionamento per record — ogni record ha un campo version. Durante la sincronizzazione, il client invia le versioni di tutti i record e il server restituisce solo quelli la cui versione è cambiata. Ciò è più efficiente della sincronizzazione snapshot, ma richiede la memorizzazione delle versioni sul client. Orologi vettoriali (Vector Clocks) — una tecnica avanzata per sistemi distribuiti in cui ogni nodo assegna la propria versione e i conflitti vengono risolti per ordine parziale.

Snapshot con diff incrementale — un approccio ibrido: snapshot completi rari (una volta al giorno) + sincronizzazione incrementale tra di essi. All’avvio dopo una lunga assenza, il client carica uno snapshot e durante sincronizzazioni frequenti — solo delta. Approccio simile a Git — ogni commit di dati ha un hash e il client sa da quale commit partire. Questo è implementato in Couchbase Lite Sync Gateway (2024) ed è il punto di riferimento per l’affidabilità.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

Regola di risoluzione della versione: se le versioni corrispondono — nessuna modifica. Se la versione locale è più recente — vince quella locale. Se la versione del server è più recente — vince il server. Solo quando le versioni sono uguali ma i dati differiscono — viene chiamato il risolutore di conflitti. Last Write Wins con flag di versione — la strategia più semplice ma affidabile.

Come costruire un Sync Engine per un’app mobile

Passo 1: Definire il modello dati — quali entità vengono sincronizzate, quanto spesso cambiano e il loro volume. Per ogni entità, definire la strategia (incrementale / completa / push) e il ritardo di sincronizzazione accettabile.

Passo 2: Scegliere un protocollo — REST con checkpoint, GraphQL con Subscriptions o gRPC con stream bidirezionale. GraphQL Subscriptions — una scelta popolare per app moderne: un unico protocollo sia per pull che per push. Apollo Client (2025) supporta la sincronizzazione offline tramite cache del dispositivo.

Passo 3: Implementare una coda offline — archivio locale delle modifiche con chiavi di idempotenza (vedi articolo «Offline Queue»). La coda è il fondamento di un Sync Engine affidabile: senza di essa, la sincronizzazione non garantisce la consegna delle modifiche.

Passo 4: Scegliere un risolutore di conflitti — LWW per casi semplici, CRDT per modifica collaborativa, merge personalizzato per logica di business. Regola: il risolutore deve essere idempotente — riapplicare la stessa operazione deve produrre lo stesso risultato.

Passo 5: Monitoraggio e metriche — registrare ogni sincronizzazione: numero di record, tempo di esecuzione, numero di conflitti, errori. Firebase Crashlytics o Sentry (2025) consentono di tracciare gli errori di sincronizzazione in tempo reale.

Secondo Realm Team (2024), un Sync Engine tipico per app mobile elabora 100–500 sincronizzazioni al giorno per dispositivo, trasferendo in media 50–200 KB di dati per sessione. Ottimizzazione del protocollo — utilizzare la compressione Protobuf invece di JSON — riduce il volume di dati trasferiti di un ulteriore 40–60%.