Sync Engine: klíčové pojmy, typy a mechanismy fungování

Co je synchronizační engine?

Sync Engine — je architektonická vrstva mezi lokální databází a vzdáleným API, která řídí tok dat v obou směrech. Jeho úkoly: sledování změn, jejich odesílání na server, přijímání změn ze serveru a řešení konfliktů. Uživatel pracuje s lokálními daty a Sync Engine je bezproblémově synchronizuje se serverem.

Sync Engine může být vestavěný (Firebase Firestore, Couchbase Lite, Realm) nebo vlastní — napsaný pro konkrétní obchodní logiku. Vestavěné enginy nabízejí hotovou funkcionalitu offline-first a řešení konfliktů. Vlastní enginy poskytují plnou kontrolu nad formátem dat, synchronizačním protokolem a politikou konfliktů.

Podle Sravana Kartika (2024), autora knihy «Mobile Sync Engine Design Patterns», je vlastní Sync Engine opodstatněný pro aplikace se složitou obchodní logikou (finance, medicína, IoT), kde jsou vlastní pravidla slučování kritická. Pro typické scénáře (poznámky, chaty, feedy) stačí vestavěný Firestore nebo 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>
}

Toto rozhraní popisuje minimální kontrakt Sync Engine: pull (stažení změn ze serveru), push (odeslání lokálních změn), resolve (zpracování konfliktů) a observe (sledování stavu synchronizace). Tato abstrakce umožňuje měnit implementaci bez úpravy prezentační vrstvy.

Typy synchronizace: plná, inkrementální a push

Full sync (plná synchronizace) — při každém sezení se stahuje celá sada dat ze serveru. Jednoduchá implementace, ale pro velké objemy nepřijatelná: stažení 10 000 záznamů při každém otevření aplikace spotřebovává data a baterii. Full sync je opodstatněný pro referenční data (seznam zemí) se vzácnými aktualizacemi.

Incremental sync (inkrementální synchronizace) — přenášejí se pouze záznamy změněné od poslední synchronizace. Server ukládá časové razítko poslední změny pro každý záznam nebo celou sadu. Klient odešle lastSyncTimestamp a obdrží pouze záznamy s updated_at > tato hodnota. Podle Instagram Engineering (2024) snižuje inkrementální synchronizace objem přenášených dat o 97 % ve srovnání s full sync.

Push sync (synchronizace iniciovaná serverem) — server sám upozorní klienta na potřebu synchronizace přes FCM (Firebase Cloud Messaging), WebSocket nebo SSE (Server-Sent Events). Klient neplýtvá zdroji na periodické dotazování. Push sync je optimální řešení pro aplikace v reálném čase: chaty, notifikace, lajky. Google Firebase Firestore používá WebSocket pro synchronizaci v reálném čase s automatickým fallbackem na HTTP polling.

Hybridní přístup — kombinace typů: při startu aplikace full sync pro základní data, poté inkrementální synchronizace pro aktualizace a pro kritické události — push sync přes FCM. To poskytuje rychlost i úsporu zdrojů.

Incremental sync — jak fungují kontrolní body a delta

Kontrolní bod — hodnota, kterou klient ukládá mezi synchronizačními sezeními. Obvykle je to updated_at posledního úspěšně synchronizovaného záznamu. Při příští synchronizaci klient odešle kontrolní bod serveru a ten vrátí všechny záznamy s updated_at novějším než kontrolní bod. Cursor-based pagination — pokročilá verze, kde server vrací kurzor (ukazatel na další stránku) spolu s daty.

Delta synchronizace — server vypočítá rozdíl mezi aktuálním stavem dat a snímkem, který viděl klient. Místo odesílání všech záznamů se přenášejí pouze operace (insert, update, delete). To je zvláště efektivní pro velké datové sady, kde se změnilo jen několik záznamů. Google Drive API (2025) používá changes.list s pageToken pro delta synchronizaci souborů.

Strategie «odložených delta» — na mobilním klientovi se změny neodesílají okamžitě, ale jsou ukládány do vyrovnávací paměti Offline Queue. Po dosažení prahu (10 operací nebo 30 sekund) se vytvoří delta balíček a odešle se na server. Podle Dropbox Mobile Engineering (2024) snížilo dávkové zpracování delta počet HTTP požadavků o 65 % a spotřebu baterie o 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 ukládá jak časové razítko, tak kurzor stránkování pro dlouhé seznamy. Dvouparametrický kontrolní bod zaručuje, že žádný záznam nebude vynechán nebo duplikován při synchronizaci velkých datových sad.

Push sync — okamžitá synchronizace přes WebSocket a FCM

WebSocket — trvalé obousměrné spojení mezi klientem a serverem. Server odesílá aktualizace ihned po změně dat. WebSocket je optimální pro aplikace v reálném čase: chaty, streamování, kolaborativní práce. Nevýhoda: spotřeba baterie a dat pro udržení spojení (heartbeat). OkHttp WebSocket na Androidu a URLSessionWebSocketTask na iOS — vestavěné implementace.

Firebase Cloud Messaging (FCM) — push notifikace, které server odesílá nikoli pro zobrazení uživateli, ale pro spuštění synchronizace. Po přijetí silent push (datové zprávy) se aplikace probudí a spustí Sync Engine. FCM nevyžaduje trvalé připojení a je úspornější než WebSocket pro řídké notifikace.

SSE (Server-Sent Events) — jednosměrný kanál, kterým server posílá události klientovi. Jednodušší na implementaci než WebSocket, ale nepodporuje obousměrnou komunikaci. EventSource API (JavaScript) a OkHttp SSE (Android) — populární knihovny. SSE je vhodné pro notifikace o nových datech, když klient nemusí odesílat data zpět stejným kanálem.

Podle WhatsApp Engineering (2024) jejich Sync Engine používá kombinaci WebSocket pro aktivní relaci a FCM pro probuzení aplikace na pozadí: WebSocket se odpojí po 5 minutách nečinnosti a následné aktualizace jsou doručeny přes silent push.

Snapshot sync a verzování dat

Snapshot-based sync — server periodicky vytváří úplný snímek dat (snapshot) a přiděluje mu verzi. Klient ukládá číslo aktuální verze. Pokud je zastaralá — stáhne nový snímek. To je jednoduchá a spolehlivá strategie, ale neefektivní pro časté změny — pokaždé se stahuje celá datová sada.

Verzování na úrovni záznamu — každý záznam má pole version. Při synchronizaci klient odešle verze všech záznamů a server vrátí pouze ty, jejichž verze se změnila. To je efektivnější než snapshot sync, ale vyžaduje ukládání verzí na klientovi. Vector Clocks — pokročilá technika pro distribuované systémy, kde každý uzel přiděluje svou verzi a konflikty se řeší podle částečného pořadí.

Snapshot s inkrementálním diff — hybridní přístup: vzácný úplný snímek (jednou denně) + inkrementální synchronizace mezi nimi. Po delší nepřítomnosti klient stáhne snímek a při častých synchronizacích — pouze delta. Přístup podobný Gitu — každý commit dat má hash a klient ví, od kterého commitu má vycházet. To je implementováno v Couchbase Lite Sync Gateway (2024) a je standardem spolehlivosti.

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

Pravidlo řešení verzí: pokud se verze shodují — žádné změny. Pokud je lokální verze novější — vítězí lokální. Pokud je serverová verze novější — vítězí server. Pouze při stejných verzích, ale rozdílných datech — je volán conflict resolver. Last Write Wins s příznakem version — nejjednodušší, ale spolehlivá strategie.

Jak postavit Sync Engine pro mobilní aplikaci

Krok 1: Definovat datový model — které entity se synchronizují, jak často se mění, jaký je objem. Pro každou entitu stanovit strategii (incremental / full / push) a povolené zpoždění synchronizace.

Krok 2: Vybrat protokol — REST s kontrolními body, GraphQL s Subscriptions nebo gRPC s obousměrným proudem. GraphQL Subscriptions — populární volba pro moderní aplikace: jeden protokol pro pull i push. Apollo Client (2025) podporuje offline synchronizaci přes cache na zařízení.

Krok 3: Implementovat Offline Queue — lokální úložiště změn s idempotentními klíči (viz článek «Offline Queue»). Fronta je základem spolehlivého Sync Engine: bez ní synchronizace nezaručuje doručení změn.

Krok 4: Vybrat conflict resolver — LWW pro jednoduché případy, CRDT pro společné editování, Custom merge pro obchodní logiku. Pravidlo: resolver musí být idempotentní — opakované použití stejné operace musí dávat stejný výsledek.

Krok 5: Monitorování a metriky — logovat každou synchronizaci: počet záznamů, doba provedení, počet konfliktů, chyby. Firebase Crashlytics nebo Sentry (2025) umožňují sledovat chyby synchronizace v reálném čase.

Podle Realm Team (2024) typický Sync Engine pro mobilní aplikaci zpracovává 100–500 synchronizací denně na zařízení, přenáší průměrně 50–200 KB dat za sezení. Optimalizace protokolu — komprese Protobuf místo JSON — snižuje objem přenášených dat o dalších 40–60 %.