Sync Engine: kulcsfogalmak, típusok és működési mechanizmusok

Mi az a szinkronizációs motor?

Sync Engine — egy architekturális réteg a helyi adatbázis és a távoli API között, amely mindkét irányban kezeli az adatáramlást. Feladatai: változások nyomon követése, elküldése a szerverre, változások fogadása a szerverről és konfliktusok feloldása. A felhasználó helyi adatokkal dolgozik, a Sync Engine pedig zökkenőmentesen szinkronizálja azokat a szerverrel.

A Sync Engine lehet beépített (Firebase Firestore, Couchbase Lite, Realm) vagy egyedi — adott üzleti logikára írva. A beépített motorok kész offline-first funkciókat és konfliktusmegoldást kínálnak. Az egyedi motorok teljes ellenőrzést adnak az adatformátum, a szinkronizációs protokoll és a konfliktuspolitika felett.

Sravan Kartik (2024), a «Mobile Sync Engine Design Patterns» című könyv szerzője szerint az egyedi Sync Engine összetett üzleti logikájú alkalmazásoknál (pénzügy, egészségügy, IoT) indokolt, ahol az egyedi összefésülési szabályok kritikusak. Tipikus forgatókönyvekhez (jegyzetek, csevegések, hírfolyamok) elegendő a beépített Firestore vagy Realm.

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

Ez az interfész írja le a Sync Engine minimális szerződését: pull (változások letöltése a szerverről), push (helyi változtatások elküldése), resolve (konfliktusok kezelése) és observe (szinkronizációs állapot megfigyelése). Ez az absztrakció lehetővé teszi a megvalósítás megváltoztatását a Prezentációs réteg módosítása nélkül.

Szinkronizációs típusok: teljes, növekményes és push

Full sync (teljes szinkronizálás) — minden munkamenetkor a teljes adatkészlet letöltődik a szerverről. Egyszerű megvalósítás, de nagy mennyiségeknél elfogadhatatlan: 10 000 rekord letöltése az alkalmazás minden megnyitásakor adatforgalmat és akkumulátort fogyaszt. A full sync ritkán frissülő referenciaadatoknál (országlista) indokolt.

Incremental sync (növekményes szinkronizálás) — csak az utolsó szinkronizálás óta megváltozott rekordok kerülnek továbbításra. A szerver tárolja az utolsó módosítás időbélyegét minden rekordhoz vagy a teljes készlethez. A kliens elküldi a lastSyncTimestamp értéket, és csak az updated_at > ezen érték rekordokat kapja meg. A Instagram Engineering (2024) adatai szerint az incremental sync 97%-kal csökkenti a továbbított adatok mennyiségét a full sync-hez képest.

Push sync (szerver által kezdeményezett szinkronizálás) — a szerver maga értesíti a klienst a szinkronizálás szükségességéről FCM (Firebase Cloud Messaging), WebSocket vagy SSE (Server-Sent Events) segítségével. A kliens nem pazarol erőforrásokat időszakos lekérdezésre. A push sync az optimális megoldás valós idejű alkalmazásokhoz: csevegések, értesítések, like-ok. Google Firebase Firestore WebSocket-et használ a valós idejű szinkronizáláshoz automatikus HTTP polling visszaeséssel.

Hibrid megközelítés — a típusok kombinációja: az alkalmazás indításakor full sync az alapadatokhoz, majd incremental sync a frissítésekhez, kritikus eseményekhez pedig push sync FCM-en keresztül. Ez sebességet és erőforrás-megtakarítást is biztosít.

Incremental sync — hogyan működnek az ellenőrző pontok és delták

Ellenőrző pont — egy érték, amelyet a kliens a szinkronizációs munkamenetek között tárol. Általában ez az utolsó sikeresen szinkronizált rekord updated_at mezője. A következő szinkronizáláskor a kliens elküldi az ellenőrző pontot a szervernek, amely visszaadja az összes updated_at az ellenőrző pontnál későbbi rekordot. Cursor-alapú lapozás — fejlettebb verzió, ahol a szerver egy kurzort (mutatót a következő oldalra) ad vissza az adatokkal együtt.

Delta szinkronizálás — a szerver kiszámítja a különbséget az adatok aktuális állapota és a kliens által látott pillanatkép között. Az összes rekord elküldése helyett csak a műveletek (insert, update, delete) kerülnek továbbításra. Ez különösen hatékony nagy adathalmazoknál, ahol csak néhány rekord változott. Google Drive API (2025) a changes.list-et használja pageToken-nel a fájlok delta szinkronizálásához.

A «késleltetett delták» stratégiája — a mobil kliensen a változtatások nem küldődnek el azonnal, hanem az Offline Queue-ban pufferelődnek. A küszöb elérésekor (10 művelet vagy 30 másodperc) egy delta csomag képződik és elküldődik a szerverre. A Dropbox Mobile Engineering (2024) adatai szerint a delták csoportosítása 65%-kal csökkentette a HTTP-kérések számát és 12%-kal az akkumulátorfogyasztást.

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
    )

A SyncCheckpoint tárolja mind az időbélyeget, mind a lapozási kurzort hosszú listákhoz. Kétparaméteres ellenőrző pont garantálja, hogy egyetlen rekord sem marad ki vagy duplikálódik nagy adathalmazok szinkronizálásakor.

Push sync — azonnali szinkronizálás WebSocket és FCM segítségével

WebSocket — állandó kétirányú kapcsolat a kliens és a szerver között. A szerver az adatok változásakor azonnal frissítéseket küld. A WebSocket valós idejű alkalmazásokhoz optimális: csevegések, streaming, együttműködő munka. Hátrány: akkumulátor- és adatforgalom-fogyasztás a kapcsolat fenntartásához (heartbeat). OkHttp WebSocket Androidon és URLSessionWebSocketTask iOS-en — beépített megvalósítások.

Firebase Cloud Messaging (FCM) — push értesítések, amelyeket a szerver nem a felhasználónak való megjelenítésre küld, hanem a szinkronizálás elindításához. Silent push (adatüzenet) fogadásakor az alkalmazás felébred és elindítja a Sync Engine-t. Az FCM nem igényel állandó kapcsolatot, és ritka értesítéseknél gazdaságosabb, mint a WebSocket.

SSE (Server-Sent Events) — egyirányú csatorna, amelyen keresztül a szerver eseményeket küld a kliensnek. Egyszerűbb megvalósítani, mint a WebSocketet, de nem támogatja a kétirányú kommunikációt. EventSource API (JavaScript) és OkHttp SSE (Android) — népszerű könyvtárak. Az SSE új adatokról szóló értesítésekhez alkalmas, amikor a kliensnek nem kell adatokat visszaküldenie ugyanazon a csatornán.

A WhatsApp Engineering (2024) adatai szerint az ő Sync Engine-jük a WebSocket és FCM kombinációját használja: a WebSocket 5 perc inaktivitás után lekapcsolódik, és a későbbi frissítések silent push segítségével érkeznek.

Snapshot sync és adatverziókezelés

Snapshot-based sync — a szerver időszakosan teljes pillanatképet (snapshot) készít az adatokról, és verziót rendel hozzá. A kliens tárolja az aktuális verziószámot. Ha elavult — új pillanatképet tölt le. Ez egy egyszerű és megbízható stratégia, de gyakori változásokhoz nem hatékony — minden alkalommal a teljes adatkészlet letöltődik.

Verziókezelés rekordszinten — minden rekord rendelkezik egy version mezővel. Szinkronizáláskor a kliens elküldi az összes rekord verzióját, a szerver pedig csak a megváltozott verziójú rekordokat adja vissza. Ez hatékonyabb, mint a snapshot sync, de a verziók kliens oldali tárolását igényli. Vector Clocks — fejlett technika elosztott rendszerekhez, ahol minden csomópont saját verziót rendel, és a konfliktusok részleges sorrend szerint oldódnak fel.

Snapshot növekményes diff-fel — hibrid megközelítés: ritka teljes pillanatkép (naponta egyszer) + növekményes szinkronizálás közöttük. Hosszú távollét után a kliens pillanatképet tölt le, gyakori szinkronizálásokkor pedig csak deltákat. Git-szerű megközelítés — minden adatkommitnek hash-je van, és a kliens tudja, melyik kommittól kell kiindulnia. Ez a Couchbase Lite Sync Gateway-ben (2024) van megvalósítva, és a megbízhatóság etalonja.

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

A verziófeloldás szabálya: ha a verziók egyeznek — nincs változás. Ha a helyi verzió újabb — a helyi nyer. Ha a szerververzió újabb — a szerver nyer. Csak egyenlő verziók, de eltérő adatok esetén hívódik meg a conflict resolver. Last Write Wins version jelzővel — a legegyszerűbb, de megbízható stratégia.

Hogyan építsünk Sync Engine-t mobilalkalmazáshoz

1. lépés: Adatmodell meghatározása — mely entitások szinkronizálódnak, milyen gyakran változnak, mekkora a mennyiségük. Minden entitáshoz határozza meg a stratégiát (incremental / full / push) és a megengedett szinkronizációs késleltetést.

2. lépés: Protokoll kiválasztása — REST ellenőrző pontokkal, GraphQL Subscriptions-szel vagy gRPC kétirányú adatfolyammal. GraphQL Subscriptions — népszerű választás modern alkalmazásokhoz: egy protokoll pull-hoz és push-hoz egyaránt. Az Apollo Client (2025) támogatja az offline szinkronizálást az eszköz gyorsítótárán keresztül.

3. lépés: Offline Queue megvalósítása — a változtatások helyi tárolója idempotencia-kulcsokkal (lásd: «Offline Queue» cikk). A sor egy megbízható Sync Engine alapja: nélküle a szinkronizálás nem garantálja a változások kézbesítését.

4. lépés: Conflict resolver kiválasztása — LWW egyszerű esetekhez, CRDT közös szerkesztéshez, Custom merge üzleti logikához. Szabály: a resolvernek idempotensnek kell lennie — ugyanazon művelet ismételt alkalmazásának ugyanazt az eredményt kell adnia.

5. lépés: Monitoring és metrikák — minden szinkronizálás naplózása: rekordok száma, végrehajtási idő, konfliktusok száma, hibák. Firebase Crashlytics vagy Sentry (2025) lehetővé teszi a szinkronizációs hibák valós idejű nyomon követését.

A Realm Team (2024) adatai szerint egy tipikus Sync Engine mobilalkalmazáshoz eszközönként naponta 100–500 szinkronizálást dolgoz fel, munkamenetenként átlagosan 50–200 KB adatot továbbítva. Protokoll optimalizálása — Protobuf tömörítés JSON helyett — további 40–60%-kal csökkenti a továbbított adatok mennyiségét.