Sync Engine: concepte cheie, tipuri și mecanisme de funcționare

Ce este motorul de sincronizare?

Sync Engine — este un strat arhitectural între baza de date locală și API-ul la distanță, care gestionează fluxul de date în ambele direcții. Sarcinile sale: urmărirea modificărilor, trimiterea lor către server, primirea modificărilor de la server și rezolvarea conflictelor. Utilizatorul lucrează cu date locale, iar Sync Engine le sincronizează perfect cu serverul.

Sync Engine poate fi încorporat (Firebase Firestore, Couchbase Lite, Realm) sau personalizat — scris pentru o logică de afaceri specifică. Motoarele încorporate oferă funcționalitate gata făcută offline-first și rezolvare a conflictelor. Cele personalizate oferă control complet asupra formatului datelor, protocolului de sincronizare și politicii de conflicte.

Potrivit Sravan Kartik (2024), autorul cărții «Mobile Sync Engine Design Patterns», un Sync Engine personalizat este justificat pentru aplicații cu logică de afaceri complexă (finanțe, medicină, IoT), unde regulile personalizate de îmbinare sunt critice. Pentru scenarii tipice (note, chaturi, fluxuri) sunt suficiente Firestore sau Realm încorporate.

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>
}

Această interfață descrie contractul minim al Sync Engine: pull (încărcarea modificărilor de pe server), push (trimiterea modificărilor locale), resolve (gestionarea conflictelor) și observe (observarea stării sincronizării). Această abstractizare permite schimbarea implementării fără a modifica stratul Presentation.

Tipuri de sincronizare: completă, incrementală și push

Full sync (sincronizare completă) — la fiecare sesiune se încarcă întregul set de date de pe server. Implementare simplă, dar inacceptabilă pentru volume mari: încărcarea a 10 000 de înregistrări la fiecare deschidere a aplicației consumă trafic și baterie. Full sync este justificat pentru date de referință (lista țărilor) cu actualizări rare.

Incremental sync (sincronizare incrementală) — se transmit doar înregistrările modificate de la ultima sincronizare. Serverul stochează timestampul ultimei modificări pentru fiecare înregistrare sau întreg setul. Clientul transmite lastSyncTimestamp și primește doar înregistrările cu updated_at > această valoare. Conform datelor Instagram Engineering (2024), sincronizarea incrementală reduce volumul de date transmise cu 97% comparativ cu full sync.

Push sync (sincronizare inițiată de server) — serverul notifică singur clientul despre necesitatea sincronizării prin FCM (Firebase Cloud Messaging), WebSocket sau SSE (Server-Sent Events). Clientul nu consumă resurse pentru polling periodic. Push sync este soluția optimă pentru aplicații în timp real: chaturi, notificări, aprecieri. Google Firebase Firestore folosește WebSocket pentru sincronizare în timp real cu fallback automat pe HTTP polling.

Abordarea hibridă — combinație de tipuri: la pornirea aplicației full sync pentru datele de bază, apoi incremental sync pentru actualizări, iar pentru evenimente critice — push sync prin FCM. Aceasta oferă atât viteză, cât și economie de resurse.

Incremental sync — cum funcționează punctele de control și delta

Punct de control — o valoare pe care clientul o stochează între sesiunile de sincronizare. De obicei este updated_at al ultimei înregistrări sincronizate cu succes. La următoarea sincronizare, clientul transmite punctul de control serverului, iar acesta returnează toate înregistrările cu updated_at mai recent decât punctul de control. Cursor-based pagination — o versiune avansată în care serverul returnează un cursor (indicator al paginii următoare) împreună cu datele.

Sincronizarea delta — serverul calculează diferența dintre starea curentă a datelor și instantaneul pe care l-a văzut clientul. În loc să trimită toate înregistrările, se transmit doar operațiile (insert, update, delete). Acest lucru este deosebit de eficient pentru seturi mari de date, unde s-au modificat doar câteva înregistrări. Google Drive API (2025) folosește changes.list cu pageToken pentru sincronizarea delta a fișierelor.

Strategia «deltelor întârziate» — pe clientul mobil, modificările nu sunt trimise imediat, ci sunt stocate în Offline Queue. La atingerea pragului (10 operații sau 30 de secunde), se formează un pachet delta și se trimite către server. Conform datelor Dropbox Mobile Engineering (2024), gruparea delta a redus numărul de cereri HTTP cu 65% și a scăzut consumul bateriei cu 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 stochează atât timestampul, cât și cursorul de paginare pentru liste lungi. Punctul de control cu doi parametri garantează că nicio înregistrare nu va fi omisă sau duplicată în timpul sincronizării seturilor mari de date.

Push sync — sincronizare instantanee prin WebSocket și FCM

WebSocket — o conexiune permanentă bidirecțională între client și server. Serverul trimite actualizări imediat după modificarea datelor. WebSocket este optim pentru aplicații în timp real: chaturi, streaming, lucru colaborativ. Dezavantaj: consum de baterie și trafic pentru menținerea conexiunii (heartbeat). OkHttp WebSocket pe Android și URLSessionWebSocketTask pe iOS — implementări încorporate.

Firebase Cloud Messaging (FCM) — notificări push pe care serverul le trimite nu pentru afișare utilizatorului, ci pentru declanșarea sincronizării. La primirea unui silent push (data message), aplicația se trezește și pornește Sync Engine. FCM nu necesită conexiune permanentă și este mai economic decât WebSocket pentru notificări rare.

SSE (Server-Sent Events) — un canal unidirecțional prin care serverul trimite evenimente clientului. Mai simplu de implementat decât WebSocket, dar nu suportă comunicarea bidirecțională. EventSource API (JavaScript) și OkHttp SSE (Android) — biblioteci populare. SSE este potrivit pentru notificări despre date noi, când clientul nu trebuie să trimită date înapoi prin același canal.

Conform datelor WhatsApp Engineering (2024), Sync Engine-ul lor folosește o combinație de WebSocket pentru sesiunea activă și FCM pentru trezirea aplicației în fundal: WebSocket se deconectează după 5 minute de inactivitate, iar actualizările ulterioare sunt livrate prin silent push.

Snapshot sync și versionarea datelor

Snapshot-based sync — serverul creează periodic un instantaneu complet al datelor (snapshot) și îi atribuie o versiune. Clientul stochează numărul versiunii curente. Dacă este învechită — încarcă un nou instantaneu. Este o strategie simplă și fiabilă, dar ineficientă pentru modificări frecvente — de fiecare dată se încarcă setul complet de date.

Versionarea la nivel de înregistrare — fiecare înregistrare are câmpul version. La sincronizare, clientul trimite versiunile tuturor înregistrărilor, iar serverul returnează doar cele a căror versiune s-a modificat. Aceasta este mai eficientă decât snapshot sync, dar necesită stocarea versiunilor pe client. Vector Clocks — o tehnică avansată pentru sisteme distribuite, unde fiecare nod atribuie propria versiune, iar conflictele sunt rezolvate după ordinea parțială.

Snapshot cu diff incremental — abordare hibridă: instantaneu complet rar (o dată pe zi) + sincronizare incrementală între ele. După o absență îndelungată, clientul încarcă snapshotul, iar la sincronizări frecvente — doar delta. Abordare asemănătoare cu Git — fiecare commit de date are un hash, iar clientul știe de la care commit să pornească. Aceasta este implementată în Couchbase Lite Sync Gateway (2024) și este un standard de fiabilitate.

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)
    }

Regula de rezolvare a versiunilor: dacă versiunile coincid — nu există modificări. Dacă versiunea locală este mai nouă — câștigă cea locală. Dacă versiunea serverului este mai nouă — câștigă serverul. Doar la versiuni egale, dar date diferite — se apelează conflict resolver. Last Write Wins cu flag version — cea mai simplă, dar fiabilă strategie.

Cum să construiești un Sync Engine pentru aplicația mobilă

Pasul 1: Definirea modelului de date — care entități se sincronizează, cât de des se modifică, ce volum au. Pentru fiecare entitate se stabilește strategia (incremental / full / push) și întârzierea admisibilă a sincronizării.

Pasul 2: Alegerea protocolului — REST cu puncte de control, GraphQL cu Subscriptions sau gRPC cu flux bidirecțional. GraphQL Subscriptions — alegere populară pentru aplicații moderne: un singur protocol atât pentru pull, cât și pentru push. Apollo Client (2025) suportă sincronizarea offline prin cache pe dispozitiv.

Pasul 3: Implementarea Offline Queue — stocare locală a modificărilor cu chei de idempotență (vezi articolul «Offline Queue»). Coada este fundamentul unui Sync Engine fiabil: fără ea, sincronizarea nu garantează livrarea modificărilor.

Pasul 4: Alegerea conflict resolver — LWW pentru cazuri simple, CRDT pentru editare colaborativă, Custom merge pentru logică de afaceri. Regula: resolverul trebuie să fie idempotent — aplicarea repetată a aceleiași operații trebuie să dea același rezultat.

Pasul 5: Monitorizare și metrici — înregistrarea fiecărei sincronizări: număr de înregistrări, timp de execuție, număr de conflicte, erori. Firebase Crashlytics sau Sentry (2025) permit urmărirea erorilor de sincronizare în timp real.

Conform datelor Realm Team (2024), un Sync Engine tipic pentru aplicația mobilă procesează 100–500 de sincronizări pe zi per dispozitiv, transmițând în medie 50–200 KB de date per sesiune. Optimizarea protocolului — compresia Protobuf în loc de JSON — reduce volumul datelor transmise cu încă 40–60%.