Sync Engine: nyckelbegrepp, typer och funktionsmekanismer

Vad är en synkroniseringsmotor?

Sync Engine — är ett arkitekturlager mellan den lokala databasen och det fjärr-API som hanterar dataflödet i båda riktningarna. Dess uppgifter: spåra ändringar, skicka dem till servern, ta emot ändringar från servern och lösa konflikter. Användaren arbetar med lokal data och Sync Engine synkroniserar den sömlöst med servern.

Sync Engine kan vara inbyggd (Firebase Firestore, Couchbase Lite, Realm) eller anpassad — skriven för specifik affärslogik. Inbyggda motorer erbjuder färdig offline-first-funktionalitet och konfliktlösning. Anpassade motorer ger full kontroll över dataformat, synkroniseringsprotokoll och konfliktpolicy.

Enligt Sravan Kartik (2024), författare till boken «Mobile Sync Engine Design Patterns», är en anpassad Sync Engine motiverad för applikationer med komplex affärslogik (finans, medicin, IoT), där anpassade sammanfogningsregler är kritiska. För typiska scenarier (anteckningar, chattar, flöden) räcker inbyggda Firestore eller 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>
}

Detta gränssnitt beskriver det minimala kontraktet för Sync Engine: pull (hämta ändringar från servern), push (skicka lokala ändringar), resolve (hantera konflikter) och observe (övervaka synkroniseringsstatus). Denna abstraktion gör det möjligt att ändra implementeringen utan att ändra presentationslagret.

Synkroniseringstyper: fullständig, inkrementell och push

Full sync (fullständig synkronisering) — varje session laddar ner hela datamängden från servern. Enkel implementering, men oacceptabel för stora volymer: att ladda ner 10 000 poster varje gång appen öppnas förbrukar trafik och batteri. Full sync är motiverad för referensdata (landslista) med sällsynta uppdateringar.

Incremental sync (inkrementell synkronisering) — endast poster som ändrats sedan senaste synkroniseringen överförs. Servern lagrar tidsstämpeln för senaste ändringen för varje post eller hela datasetet. Klienten skickar lastSyncTimestamp och får endast poster med updated_at > detta värde. Enligt Instagram Engineering (2024) minskar inkrementell synkronisering datavolymen med 97% jämfört med full sync.

Push sync (serverinitierad synkronisering) — servern meddelar själv klienten om behovet av synkronisering via FCM (Firebase Cloud Messaging), WebSocket eller SSE (Server-Sent Events). Klienten förbrukar inte resurser på periodisk polling. Push sync är den optimala lösningen för realtidsapplikationer: chattar, notifieringar, gilla-markeringar. Google Firebase Firestore använder WebSocket för realtidssynkronisering med automatisk återgång till HTTP-polling.

Hybridansats — kombination av typer: vid appstart full sync för grunddata, sedan inkrementell synkronisering för uppdateringar och för kritiska händelser — push sync via FCM. Detta ger både hastighet och resursbesparing.

Incremental sync — hur kontrollpunkter och deltan fungerar

Kontrollpunkt — ett värde som klienten lagrar mellan synkroniseringssessioner. Vanligtvis är det updated_at för den senaste framgångsrikt synkroniserade posten. Vid nästa synkronisering skickar klienten kontrollpunkten till servern, som returnerar alla poster med updated_at senare än kontrollpunkten. Cursor-baserad paginering — en avancerad version där servern returnerar en markör (pekare till nästa sida) tillsammans med data.

Delta-synkronisering — servern beräknar skillnaden mellan datans aktuella tillstånd och den ögonblicksbild som klienten såg. I stället för att skicka alla poster överförs endast operationer (insert, update, delete). Detta är särskilt effektivt för stora dataset där endast ett fåtal poster har ändrats. Google Drive API (2025) använder changes.list med pageToken för delta-synkronisering av filer.

Strategin «fördröjda deltan» — på den mobila klienten skickas ändringar inte omedelbart, utan buffras i Offline Queue. När ett tröskelvärde uppnås (10 operationer eller 30 sekunder) bildas ett deltapaket och skickas till servern. Enligt Dropbox Mobile Engineering (2024) minskade batchhantering av deltan antalet HTTP-förfrågningar med 65% och batteriförbrukningen med 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 lagrar både tidsstämpel och pagineringsmarkör för långa listor. Tvåparametrig kontrollpunkt garanterar att ingen post missas eller dupliceras vid synkronisering av stora dataset.

Push sync — omedelbar synkronisering via WebSocket och FCM

WebSocket — en permanent tvåve4gsförbindelse mellan klient och server. Servern skickar uppdateringar omedelbart när data ändras. WebSocket är optimal för realtidsapplikationer: chattar, streaming, samarbetsarbete. Nackdel: batteri- och trafikförbrukning för att upprätthålla anslutningen (heartbeat). OkHttp WebSocket på Android och URLSessionWebSocketTask på iOS — inbyggda implementeringar.

Firebase Cloud Messaging (FCM) — push-notiser som servern skickar inte för att visas för användaren, utan för att utlösa synkronisering. Vid mottagning av en silent push (datameddelande) vaknar appen och startar Sync Engine. FCM kräver ingen permanent anslutning och är mer ekonomiskt än WebSocket för sällsynta notiser.

SSE (Server-Sent Events) — en enkelriktad kanal där servern skickar händelser till klienten. Enklare att implementera än WebSocket, men stödjer inte tvåvägskommunikation. EventSource API (JavaScript) och OkHttp SSE (Android) — populära bibliotek. SSE är lämpligt för notiser om ny data när klienten inte behöver skicka data tillbaka via samma kanal.

Enligt WhatsApp Engineering (2024) använder deras Sync Engine en kombination av WebSocket för aktiv session och FCM för att väcka appen i bakgrunden: WebSocket kopplas från efter 5 minuters inaktivitet och efterföljande uppdateringar levereras via silent push.

Snapshot sync och dataversionhantering

Snapshot-based sync — servern skapar periodvis en fullständig ögonblicksbild (snapshot) av data och tilldelar den en version. Klienten lagrar det aktuella versionsnumret. Om den är föråldrad — laddar den en ny ögonblicksbild. Detta är en enkel och pålitlig strategi, men ineffektiv för frekventa ändringar — varje gång laddas hela datasetet.

Versionshantering på postnivå — varje post har ett fält version. Vid synkronisering skickar klienten versionerna av alla poster och servern returnerar endast de vars version har ändrats. Detta är effektivare än snapshot sync, men kräver lagring av versioner på klienten. Vector Clocks — en avancerad teknik för distribuerade system där varje nod tilldelar sin egen version och konflikter löses enligt partiell ordning.

Snapshot med inkrementell diff — hybridansats: sällsynt fullständig ögonblicksbild (en gång om dagen) + inkrementell synkronisering däremellan. Efter lång frånvaro laddar klienten en ögonblicksbild och vid frekventa synkroniseringar — endast deltan. Git-liknande ansats — varje datacommit har en hash och klienten vet vilken commit den ska utgå från. Detta implementeras i Couchbase Lite Sync Gateway (2024) och är en standard för tillförlitlighet.

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

Regel för versionslösning: om versionerna matchar — inga ändringar. Om den lokala versionen är nyare — vinner den lokala. Om serverversionen är nyare — vinner servern. Endast vid lika versioner men olika data — anropas conflict resolvern. Last Write Wins med version-flagga — den enklaste men pålitliga strategin.

Hur man bygger en Sync Engine för en mobil applikation

Steg 1: Definiera datamodell — vilka entiteter synkroniseras, hur ofta de ändras, vilken volym. För varje entitet fastställs strategi (incremental / full / push) och tillåten synkroniseringsfördröjning.

Steg 2: Välj protokoll — REST med kontrollpunkter, GraphQL med Subscriptions eller gRPC med tvåvägsström. GraphQL Subscriptions — ett populärt val för moderna applikationer: ett protokoll för både pull och push. Apollo Client (2025) stödjer offline-synkronisering via cache på enheten.

Steg 3: Implementera Offline Queue — lokal lagring av ändringar med idempotensnycklar (se artikeln «Offline Queue»). Kön är grunden för en tillförlitlig Sync Engine: utan den garanterar synkroniseringen inte leverans av ändringar.

Steg 4: Välj conflict resolver — LWW för enkla fall, CRDT för gemensam redigering, Custom merge för affärslogik. Regel: resolvern måste vara idempotent — upprepad tillämpning av samma operation måste ge samma resultat.

Steg 5: Övervakning och mätvärden — logga varje synkronisering: antal poster, exekveringstid, antal konflikter, fel. Firebase Crashlytics eller Sentry (2025) gör det möjligt att spåra synkroniseringsfel i realtid.

Enligt Realm Team (2024) bearbetar en typisk Sync Engine för mobila applikationer 100–500 synkroniseringar per dag per enhet och överför i genomsnitt 50–200 KB data per session. Protokolloptimering — Protobuf-komprimering istället för JSON — minskar datavolymen med ytterligare 40–60%.