Sync Engine: kluczowe pojęcia, typy i mechanizmy działania

Czym jest silnik synchronizacji?

Sync Engine — to warstwa architektoniczna między lokalną bazą danych a zdalnym API, która zarządza przepływem danych w obu kierunkach. Jego zadania: śledzić zmiany, wysyłać je na serwer, odbierać zmiany z serwera i rozwiązywać konflikty. Użytkownik pracuje z lokalnymi danymi, a Sync Engine bezszelestnie synchronizuje je z serwerem.

Sync Engine może być wbudowany (Firebase Firestore, Couchbase Lite, Realm) lub niestandardowy — napisany pod konkretną logikę biznesową. Wbudowane silniki oferują gotową funkcjonalność offline-first i rozwiązywania konfliktów. Niestandardowe dają pełną kontrolę nad formatem danych, protokołem synchronizacji i polityką konfliktów.

Według Sravana Kartika (2024), autora książki «Mobile Sync Engine Design Patterns», niestandardowy Sync Engine jest uzasadniony dla aplikacji ze złożoną logiką biznesową (finanse, medycyna, IoT), gdzie niestandardowe reguły scalania są krytyczne. Dla typowych scenariuszy (notatki, czaty, kanały) wystarczy wbudowany Firestore lub 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>
}

Ten interfejs opisuje minimalny kontrakt Sync Engine: pull (pobieranie zmian z serwera), push (wysyłanie lokalnych zmian), resolve (obsługa konfliktów) i observe (obserwacja stanu synchronizacji). Taka abstrakcja pozwala zmieniać implementację bez modyfikacji warstwy Presentation.

Typy synchronizacji: pełna, przyrostowa i push

Full sync (pełna synchronizacja) — przy każdej sesji pobierany jest cały zbiór danych z serwera. Prosta implementacja, ale nieakceptowalna dla dużych objętości: pobranie 10 000 rekordów przy każdym otwarciu aplikacji zużywa transfer i baterię. Full sync jest uzasadniony dla danych referencyjnych (lista krajów) z rzadkimi aktualizacjami.

Incremental sync (synchronizacja przyrostowa) — przesyłane są tylko rekordy, które zmieniły się od ostatniej synchronizacji. Serwer przechowuje znacznik czasu ostatniej zmiany dla każdego rekordu lub całego zbioru. Klient przekazuje lastSyncTimestamp i otrzymuje tylko rekordy z updated_at > ta wartość. Według danych Instagram Engineering (2024), incremental sync zmniejsza objętość przesyłanych danych o 97% w porównaniu z full sync.

Push sync (synchronizacja inicjowana przez serwer) — serwer sam powiadamia klienta o potrzebie synchronizacji przez FCM (Firebase Cloud Messaging), WebSocket lub SSE (Server-Sent Events). Klient nie marnuje zasobów na okresowe polling. Push sync to optymalne rozwiązanie dla aplikacji czasu rzeczywistego: czaty, powiadomienia, polubienia. Google Firebase Firestore używa WebSocket do synchronizacji czasu rzeczywistego z automatycznym fallback na HTTP polling.

Podejście hybrydowe — kombinacja typów: przy starcie aplikacji full sync dla danych podstawowych, następnie incremental sync dla aktualizacji, a dla krytycznych zdarzeń — push sync przez FCM. To zapewnia i szybkość, i oszczędność zasobów.

Incremental sync — jak działają punkty kontrolne i delty

Punkt kontrolny — wartość, którą klient przechowuje między sesjami synchronizacji. Zazwyczaj jest to updated_at ostatniego pomyślnie zsynchronizowanego rekordu. Przy następnej synchronizacji klient przekazuje punkt kontrolny serwerowi, a ten zwraca wszystkie rekordy z updated_at późniejszym niż punkt kontrolny. Cursor-based pagination — zaawansowana wersja, gdzie serwer zwraca kursor (wskaźnik następnej strony) wraz z danymi.

Synchronizacja delta — serwer oblicza różnicę między bieżącym stanem danych a zrzutem, który widział klient. Zamiast wysyłać wszystkie rekordy, przesyłane są tylko operacje (insert, update, delete). Jest to szczególnie efektywne dla dużych zbiorów danych, gdzie zmieniło się tylko kilka rekordów. Google Drive API (2025) używa changes.list z pageToken do synchronizacji delta plików.

Strategia «opóźnionych delt» — na kliencie mobilnym zmiany nie są wysyłane natychmiast, ale buforowane w Offline Queue. Po osiągnięciu progu (10 operacji lub 30 sekund) tworzony jest pakiet delta i wysyłany na serwer. Według danych Dropbox Mobile Engineering (2024), łączenie delt w paczki zmniejszyło liczbę zapytań HTTP o 65% i obniżyło zużycie baterii 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 przechowuje zarówno znacznik czasu, jak i kursor paginacji dla długich list. Dwuparametryczny punkt kontrolny gwarantuje, że żaden rekord nie zostanie pominięty ani zduplikowany podczas synchronizacji dużych zbiorów danych.

Push sync — błyskawiczna synchronizacja przez WebSocket i FCM

WebSocket — stałe dwukierunkowe połączenie między klientem a serwerem. Serwer wysyła aktualizacje natychmiast po zmianie danych. WebSocket jest optymalny dla aplikacji czasu rzeczywistego: czaty, streaming, praca kolaboracyjna. Minus: zużycie baterii i transferu na utrzymanie połączenia (heartbeat). OkHttp WebSocket na Androidzie i URLSessionWebSocketTask na iOS — wbudowane implementacje.

Firebase Cloud Messaging (FCM) — powiadomienia push, które serwer wysyła nie do wyświetlenia użytkownikowi, ale do wyzwolenia synchronizacji. Po otrzymaniu silent push (data message) aplikacja budzi się i uruchamia Sync Engine. FCM nie wymaga stałego połączenia i jest bardziej oszczędny niż WebSocket dla rzadkich powiadomień.

SSE (Server-Sent Events) — jednostronny kanał, przez który serwer wysyła zdarzenia do klienta. Prostszy w implementacji niż WebSocket, ale nie obsługuje komunikacji dwukierunkowej. EventSource API (JavaScript) i OkHttp SSE (Android) — popularne biblioteki. SSE nadaje się do powiadomień o nowych danych, gdy klient nie musi wysyłać danych z powrotem przez ten sam kanał.

Według danych WhatsApp Engineering (2024), ich Sync Engine używa kombinacji WebSocket dla aktywnej sesji i FCM do budzenia aplikacji w tle: WebSocket wyłącza się po 5 minutach nieaktywności, a kolejne aktualizacje są dostarczane przez silent push.

Snapshot sync i wersjonowanie danych

Snapshot-based sync — serwer okresowo tworzy pełny zrzut danych (snapshot) i przypisuje mu wersję. Klient przechowuje numer bieżącej wersji. Jeśli jest nieaktualna — ładuje nowy zrzut. To prosta i niezawodna strategia, ale nieefektywna przy częstych zmianach — za każdym razem pobierany jest pełny zbiór danych.

Wersjonowanie na poziomie rekordu — każdy rekord ma pole version. Podczas synchronizacji klient wysyła wersje wszystkich rekordów, a serwer zwraca tylko te, których wersja się zmieniła. Jest to efektywniejsze niż snapshot sync, ale wymaga przechowywania wersji na kliencie. Vector Clocks — zaawansowana technika dla systemów rozproszonych, gdzie każdy węzeł przypisuje swoją wersję, a konflikty są rozwiązywane według częściowego porządku.

Snapshot z przyrostowym diff — podejście hybrydowe: rzadki pełny snapshot (raz dziennie) + incremental sync pomiędzy nimi. Po dłuższej nieobecności klient ładuje snapshot, a przy częstych synchronizacjach — tylko delty. Podejście podobne do Gita — każdy commit danych ma hash, a klient wie, od którego commitu ma się odnieść. Jest to zrealizowane w Couchbase Lite Sync Gateway (2024) i stanowi wzorzec niezawodności.

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

Zasada rozwiązywania wersji: jeśli wersje są zgodne — brak zmian. Jeśli wersja lokalna jest nowsza — wygrywa lokalna. Jeśli serwerowa jest nowsza — wygrywa serwerowa. Tylko przy równych wersjach, ale różnych danych — wywoływany jest conflict resolver. Last Write Wins z flagą version — najprostsza, ale niezawodna strategia.

Jak zbudować Sync Engine dla aplikacji mobilnej

Krok 1: Określić model danych — które encje są synchronizowane, jak często się zmieniają, jaka jest objętość. Dla każdej encji ustalić strategię (incremental / full / push) i dopuszczalne opóźnienie synchronizacji.

Krok 2: Wybrać protokół — REST z punktami kontrolnymi, GraphQL z Subscriptions lub gRPC z bidirectional stream. GraphQL Subscriptions — popularny wybór dla nowoczesnych aplikacji: jeden protokół zarówno do pull, jak i push. Apollo Client (2025) obsługuje offline sync przez cache na urządzeniu.

Krok 3: Zaimplementować Offline Queue — lokalny magazyn zmian z kluczami idempotentności (patrz artykuł «Offline Queue»). Kolejka to fundament niezawodnego Sync Engine: bez niej synchronizacja nie gwarantuje dostarczenia zmian.

Krok 4: Wybrać conflict resolver — LWW dla prostych przypadków, CRDT do wspólnego edytowania, Custom merge dla logiki biznesowej. Zasada: resolver musi być idempotentny — wielokrotne zastosowanie tej samej operacji powinno dawać ten sam wynik.

Krok 5: Monitorowanie i metryki — logować każdą synchronizację: liczba rekordów, czas wykonania, liczba konfliktów, błędy. Firebase Crashlytics lub Sentry (2025) pozwalają śledzić błędy synchronizacji w czasie rzeczywistym.

Według danych Realm Team (2024), typowy Sync Engine dla aplikacji mobilnej przetwarza 100–500 synchronizacji dziennie na urządzenie, przesyłając średnio 50–200 KB danych na sesję. Optymalizacja protokołu — kompresja Protobuf zamiast JSON — zmniejsza objętość przesyłanych danych o kolejne 40–60%.