Sync Engine: Schlüsselkonzepte, Typen und Arbeitsmechanismen

Was ist eine Sync-Engine?

Sync Engine — ist eine Architekturschicht zwischen der lokalen Datenbank und einer Remote-API, die den Datenfluss in beide Richtungen verwaltet. Zu seinen Aufgaben gehören: Änderungen verfolgen, an den Server senden, Änderungen vom Server empfangen und Konflikte lösen. Der Benutzer interagiert mit lokalen Daten, während die Sync-Engine sie nahtlos mit dem Server synchronisiert.

Sync Engine kann integriert (Firebase Firestore, Couchbase Lite, Realm) oder benutzerdefiniert sein — für spezifische Geschäftslogik geschrieben. Integrierte Engines bieten vorgefertigte Offline-First-Funktionalität und Konfliktlösung. Benutzerdefinierte Engines bieten volle Kontrolle über Datenformat, Synchronisationsprotokoll und Konfliktrichtlinie.

Laut Sravana Karthik (2024), Autor von «Mobile Sync Engine Design Patterns», ist eine benutzerdefinierte Sync Engine für Apps mit komplexer Geschäftslogik (Finanzen, Gesundheitswesen, IoT) gerechtfertigt, wo benutzerdefinierte Zusammenführungsregeln entscheidend sind. Für typische Szenarien (Notizen, Chats, Feeds) reicht ein integrierter Firestore oder Realm aus.

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

Diese Schnittstelle beschreibt den minimalen Vertrag einer Sync-Engine: pull (Laden von Serveränderungen), push (Senden lokaler Änderungen), resolve (Behandlung von Konflikten) und observe (Überwachung des Synchronisationsstatus). Diese Abstraktion ermöglicht eine Änderung der Implementierung ohne Änderung der Präsentationsebene.

Synchronisationsarten: vollständig, inkrementell und Push

Vollsynchronisation (Full Sync) — jede Sitzung lädt den gesamten Datensatz vom Server. Einfach zu implementieren, aber für große Datenmengen ungeeignet: jedes Mal 10.000 Datensätze herunterzuladen verbraucht Traffic und Akku. Die Vollsynchronisation ist für Referenzdaten (Länderliste) mit seltenen Aktualisierungen gerechtfertigt.

Inkrementelle Synchronisation — es werden nur die seit der letzten Synchronisation geänderten Datensätze übertragen. Der Server speichert den Zeitstempel der letzten Änderung für jeden Datensatz oder den gesamten Satz. Der Client sendet lastSyncTimestamp und erhält nur Datensätze mit updated_at > diesem Wert. Laut Instagram Engineering (2024) reduziert die inkrementelle Synchronisation das Übertragungsvolumen um 97% im Vergleich zur Vollsynchronisation.

Push-Synchronisation (Server-initiiert) — der Server selbst benachrichtigt den Client über die Notwendigkeit der Synchronisation per FCM (Firebase Cloud Messaging), WebSocket oder SSE (Server-Sent Events). Der Client verschwendet keine Ressourcen für regelmäßiges Polling. Push-Synchronisation ist die optimale Wahl für Echtzeit-Apps: Chats, Benachrichtigungen, Likes. Google Firebase Firestore verwendet WebSocket für Echtzeit-Synchronisation mit automatischem Fallback auf HTTP-Polling.

Hybrider Ansatz — eine Kombination der Typen: Vollsynchronisation für Basisdaten beim App-Start, dann inkrementelle Synchronisation für Aktualisierungen und für kritische Ereignisse Push-Synchronisation über FCM. Dies bietet sowohl Geschwindigkeit als auch Ressourcenschonung.

Inkrementelle Synchronisation — wie Prüfpunkte und Deltas funktionieren

Prüfpunkt (Checkpoint) — ein Wert, den der Client zwischen Synchronisationssitzungen speichert. Normalerweise ist dies der updated_at des zuletzt erfolgreich synchronisierten Datensatzes. Bei der nächsten Synchronisation sendet der Client den Prüfpunkt an den Server, und der Server gibt alle Datensätze mit updated_at nach dem Prüfpunkt zurück. Cursor-basierte Paginierung — eine erweiterte Version, bei der der Server zusammen mit den Daten einen Cursor (Zeiger auf die nächste Seite) zurückgibt.

Delta-Synchronisation — der Server berechnet die Differenz zwischen dem aktuellen Datenzustand und dem Snapshot, den der Client zuletzt gesehen hat. Anstatt aller Datensätze werden nur die Operationen (Insert, Update, Delete) übertragen. Dies ist besonders effektiv für große Datensätze, bei denen sich nur wenige Datensätze geändert haben. Google Drive API (2025) verwendet changes.list mit pageToken für die Delta-Synchronisation von Dateien.

Strategie der «aufgeschobenen Deltas» — auf dem mobilen Client werden Änderungen nicht sofort gesendet, sondern in der Offline-Warteschlange gepuffert. Wenn der Schwellenwert erreicht ist (10 Operationen oder 30 Sekunden), wird ein Delta-Paket erstellt und an den Server gesendet. Laut Dropbox Mobile Engineering (2024) hat die Delta-Bündelung die Anzahl der HTTP-Anfragen um 65% reduziert und den Akkuverbrauch um 12% gesenkt.

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 speichert sowohl den Zeitstempel als auch den Paginierungscursor für lange Listen. Zwei-Parameter-Prüfpunkt garantiert, dass bei der Synchronisation großer Datensätze kein Datensatz übersprungen oder dupliziert wird.

Push-Synchronisation — sofortige Synchronisation über WebSocket und FCM

WebSocket — eine persistente bidirektionale Verbindung zwischen Client und Server. Der Server sendet Aktualisierungen sofort, wenn sich Daten ändern. WebSocket ist optimal für Echtzeit-Apps: Chats, Streaming, Zusammenarbeit. Nachteil: Akku- und Traffic-Verbrauch für die Aufrechterhaltung der Verbindung (Heartbeat). OkHttp WebSocket auf Android und URLSessionWebSocketTask auf iOS — integrierte Implementierungen.

Firebase Cloud Messaging (FCM) — Push-Benachrichtigungen, die der Server nicht zum Anzeigen für den Benutzer sendet, sondern um die Synchronisation auszulösen. Beim Empfang eines Silent Push (Datenmitteilung) erwacht die App und startet die Sync-Engine. FCM benötigt keine dauerhafte Verbindung und ist für seltene Benachrichtigungen sparsamer als WebSocket.

SSE (Server-Sent Events) — ein unidirektionaler Kanal, über den der Server Ereignisse an den Client sendet. Einfacher zu implementieren als WebSocket, unterstützt jedoch keine bidirektionale Kommunikation. EventSource API (JavaScript) und OkHttp SSE (Android) — beliebte Bibliotheken. SSE eignet sich für Benachrichtigungen über neue Daten, wenn der Client keine Daten über denselben Kanal zurücksenden muss.

Laut WhatsApp Engineering (2024) verwendet ihre Sync-Engine eine Kombination aus WebSocket für aktive Sitzungen und FCM zum Aufwecken der App im Hintergrund: WebSocket trennt nach 5 Minuten Inaktivität die Verbindung, und nachfolgende Aktualisierungen werden über Silent Push zugestellt.

Snapshot-Synchronisation und Datenversionierung

Snapshot-basierte Synchronisation — der Server erstellt regelmäßig einen vollständigen Daten-Snapshot und weist ihm eine Version zu. Der Client speichert die aktuelle Versionsnummer. Wenn sie veraltet ist — lädt er einen neuen Snapshot herunter. Dies ist eine einfache und zuverlässige Strategie, aber ineffizient bei häufigen Änderungen — jedes Mal wird der gesamte Datensatz heruntergeladen.

Versionierung pro Datensatz — jeder Datensatz hat ein version-Feld. Während der Synchronisation sendet der Client die Versionen aller Datensätze, und der Server gibt nur diejenigen zurück, deren Version sich geändert hat. Dies ist effizienter als die Snapshot-Synchronisation, erfordert aber das Speichern von Versionen auf dem Client. Vektoruhr (Vector Clocks) — eine fortschrittliche Technik für verteilte Systeme, bei der jeder Knoten seine eigene Version zuweist und Konflikte durch partielle Ordnung gelöst werden.

Snapshot mit inkrementellem Diff — ein hybrider Ansatz: seltene vollständige Snapshots (einmal täglich) + inkrementelle Synchronisation dazwischen. Beim Start nach langer Abwesenheit lädt der Client einen Snapshot und bei häufigen Synchronisationen nur Deltas. Git-ähnlicher Ansatz — jeder Daten-Commit hat einen Hash, und der Client weiß, von welchem Commit er ausgehen muss. Dies ist in Couchbase Lite Sync Gateway (2024) implementiert und der Goldstandard für Zuverlässigkeit.

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

Versionsauflösungsregel: Wenn die Versionen übereinstimmen — gibt es keine Änderungen. Wenn die lokale Version neuer ist — gewinnt die lokale. Wenn die Serverversion neuer ist — gewinnt der Server. Nur wenn die Versionen gleich sind, sich die Daten aber unterscheiden — wird der Konfliktlöser aufgerufen. Last Write Wins mit Versionsflag — die einfachste, aber zuverlässige Strategie.

So erstellen Sie einen Sync Engine für eine mobile App

Schritt 1: Datenmodell definieren — welche Entitäten synchronisiert werden, wie oft sie sich ändern und ihr Volumen. Für jede Entität die Strategie (inkrementell / vollständig / Push) und die akzeptable Synchronisationsverzögerung festlegen.

Schritt 2: Protokoll auswählen — REST mit Prüfpunkten, GraphQL mit Subscriptions oder gRPC mit bidirektionalem Stream. GraphQL Subscriptions — eine beliebte Wahl für moderne Apps: ein Protokoll sowohl für Pull als auch Push. Apollo Client (2025) unterstützt Offline-Synchronisation über den Geräte-Cache.

Schritt 3: Offline-Warteschlange implementieren — lokales Speichern von Änderungen mit Idempotenzschlüsseln (siehe Artikel «Offline Queue»). Die Warteschlange ist die Grundlage einer zuverlässigen Sync-Engine: Ohne sie garantiert die Synchronisation nicht die Zustellung von Änderungen.

Schritt 4: Konfliktlöser auswählen — LWW für einfache Fälle, CRDT für gemeinsame Bearbeitung, benutzerdefinierte Zusammenführung für Geschäftslogik. Regel: Der Konfliktlöser muss idempotent sein — die erneute Anwendung derselben Operation muss dasselbe Ergebnis liefern.

Schritt 5: Überwachung und Metriken — jede Synchronisation protokollieren: Anzahl der Datensätze, Ausführungszeit, Anzahl der Konflikte, Fehler. Firebase Crashlytics oder Sentry (2025) ermöglichen die Verfolgung von Synchronisationsfehlern in Echtzeit.

Laut Realm Team (2024) verarbeitet eine typische mobile Sync-Engine 100–500 Synchronisationen pro Tag pro Gerät und überträgt durchschnittlich 50–200 KB Daten pro Sitzung. Protokolloptimierung — Verwendung von Protobuf-Kompression anstelle von JSON — reduziert das Übertragungsvolumen um weitere 40–60%.