Conflict Resolution: strategier, sammanslagning och funktionsprincip

Vad är konfliktlösning i mobila appar?

Konfliktlösning är processen att föra distribuerad data till ett enhetligt konsekvent tillstånd efter upptäckten av motstridiga ändringar. I centraliserade system uppstår inga konflikter: servern behandlar förfrågningar sekventiellt. I mobila appar med offlineläge ändrar klienten data lokalt och synkroniserar med servern senare. Om två klienter har ändrat samma objekt, får servern två versioner med samma identifikator men olika innehåll.

Konflikter är oundvikliga vid löst kopplad replikering (eventual consistency), när systemet offrar omedelbar konsekvens för tillgänglighet och prestanda. Enligt forskare från Princeton University (Aggarwal et al., GEO paper, KDD 2024) uppvisar system med fördröjd replikering 28 % högre prestanda vid toppbelastning, men kräver konfliktlösningsmekanismer för korrekt funktion.

Lösningsstrategin är en algoritm som systemet tillämpar automatiskt vid upptäckt av en konflikt. Olika databaser och ramverk implementerar olika strategier: Firebase Realtime Database använder LWW, CouchDB lägger till Merge-stöd, och Figma och Notion bygger arkitekturen på CRDT.

Varför uppstår konflikter vid datasynkronisering

Huvudorsaken till konflikter är samtidiga ändringar av samma resurs av två eller fler klienter som arbetar med en lokal kopia av data. Typiskt scenario: användare A redigerar en uppgift i Trello offline, medan användare B ändrar beskrivningen av samma uppgift på en annan enhet. Båda sparar sina versioner lokalt. När enheterna ansluter till nätverket får servern två olika värden för samma fält.

Ytterligare faktorer är nätverksfördröjningar och nätverkspartitionering (network partition). I distribuerade databaser som använder Raft- eller Paxos-protokollet kan en konflikt uppstå när klusterledaren är tillfälligt otillgänglig och förfrågningar bearbetas av olika noder. Enligt Amazon DynamoDB whitepaper (2025) leder cirka 0,3 % av alla skrivoperationer i skalbara NoSQL-system till upptäckbara konflikter.

Konflikter uppstår också på grund av olämplig datastruktur. Om appen lagrar en operationsräknare eller deltagarlista kan två offline-klienter utföra operationer som är sekventiellt inkompatibla. Till exempel lägger klient A till ett element i slutet av listan, medan klient B tar bort ett element från mitten — vid synkronisering vet servern inte vilken åtgärd som ska tillämpas först.

Last Write Wins — strategin för vinnaren enligt tid

Last Write Wins (LWW) — strategi där posten med den senaste tidsstämpeln väljs bland konkurrerande versioner. Systemet jämför varje versions tidsstämpel och accepterar den nyare, och kasserar den gamla. Detta är en deterministisk mekanism: med samma uppsättning stämplar är resultatet alltid detsamma, vilket eliminerar osäkerhet. LWW är implementerat i Firebase Realtime Database, Apache Cassandra och Riak KV.

I mobila appar är LWW särskilt attraktivt på grund av enkelheten i implementeringen. Klienten behöver inte analysera skillnaden mellan versioner, lagra ändringshistorik eller visa en valdialog för användaren. Servern fattar beslutet på millisekunder. LWW har dock en grundläggande nackdel — dataförlust. Om två användare samtidigt fyller i olika fält i ett formulär kommer en av deras versioner att kasseras helt.

Exempel på hur LWW fungerar i en mobil anteckningsapp med synkronisering via REST API:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

Funktionen resolveWithLWW jämför tidsstämplar och returnerar den aktuella versionen. Vid lika tidsstämpel (vilket händer vid hög skrivfrekvens) vinner vanligtvis den lokala versionen.

Merge Strategy — sammanslagning av motstridiga versioner

Merge Strategy — tillvägagångssätt där systemet inte kastar bort en av versionerna helt, utan försöker kombinera ändringarna från båda till ett konsekvent tillstånd. Detta är analogt med sammanslagning av grenar i Git: varje konflikt löses på nivån av enskilda fält eller operationer. Merge-strategier delas in i automatiska (CRDT, OT) och manuella (användaren väljer variant).

Den mest kända implementeringen är trevägssammanslagning (three-way merge). Systemet lagrar tre versioner: lokal, fjärr och deras gemensamma anfader (basversionen före divergens). Om ett fält har ändrats av endast en klient accepteras ändringen automatiskt. Om båda klienterna har ändrat samma fält — registreras en konflikt som kräver lösning. CouchDB och PouchDB använder aktivt denna modell för dokumentsynkronisering.

Exempel på implementering av trevägssammanslagning för en användarprofil:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

Trevägssammanslagning är effektiv när datastrukturen är tillräckligt stabil. Problem uppstår vid omdöpning av fält, ändring av typer och operationer med arrayer — i dessa fall krävs mer komplex logik.

CRDT — konfliktfria datastrukturer

CRDT (Conflict-Free Replicated Data Type) — matematisk modell som garanterar konvergens av data utan central samordnare. CRDT är utformade så att alla operationer är kommutativa: ordningen för tillämpning påverkar inte slutresultatet. Detta uppnås genom algebraiska egenskaper: sammanslagning av CRDT ger alltid samma resultat oavsett ordningen för mottagning av ändringar.

Huvudtyperna av CRDT inkluderar G-Counter (räknare som endast stöder ökning), PN-Counter (räknare med ökning och minskning), LWW-Register (register med versionshantering) och OR-Set (mängd som spårar tillägg och borttagning). Varje typ garanterar att sammanslagning av två repliker inte kommer att skapa konflikter. Enligt forskning från INRIA (Marc Shapiro et al., 2024) tillhandahåller CRDT deterministisk konvergens för 95 % av vanliga datatyper.

Exempel på G-Counter — en räknare som bara kan ökas:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

GCounter garanterar korrektheten av sammanslagning eftersom varje nod endast lagrar sin egen räknare, och merge tar maximum för varje nod. Detta är ett klassiskt exempel på en konfliktfri struktur som används i decentraliserade system.

Hur man väljer en konfliktlösningsstrategi

Val av strategi beror på datans natur och användningsscenarier. LWW är optimalt för appar där den senaste versionen alltid har prioritet — nyhetsflöde, notiser, statusar. Merge Strategy är lämplig för strukturerade dokument där varje fält är oberoende — användarprofiler, formulär, konfigurationer. CRDT är idealiskt för samarbetsredigering, listor och räknare i distribuerade system.

Vid val av strategi bedöms tre faktorer: datakonsekvens, prestanda och implementeringskomplexitet. LWW ger maximal prestanda och minimal komplexitet, men kan förlora data. Merge ger hög noggrannhet, men kräver en mekanism för att upptäcka ändringar på fältnivå. CRDT garanterar matematisk korrekthet, men inför begränsningar på datatyper och metadata-storlek.

I praktiken används ofta ett kombinerat tillvägagångssätt: system använder LWW för metadata, Merge för dokumentinnehåll och CRDT för liststrukturer. Firebase Firestore tillämpar till exempel LWW för fält på högsta nivå och stödjer transaktioner för atomära uppdateringar. CouchDB använder Merge med lagring av ändringshistorik. Figma och Notion bygger arkitektur baserad på CRDT för fleranvändarredigering i realtid.