Last Write Wins: vad är det, mekanism och funktionsprincip

Vad är Last Write Wins inom mobil utveckling?

Last Write Wins (LWW) — är strategin för senaste skrivning vid lösning av synkroniseringskonflikter. När två klienter ändrar samma dataobjekt tar servern emot båda versionerna och väljer den med den större tidsstämpeln (timestamp). LWW är standardstrategin i många distribuerade system: Firebase Realtime Database, Apache Cassandra, Riak KV och DynamoDB i senaste-skrivningsläge.

I mobila appar är LWW attraktivt av tre anledningar: enkel implementering, minimal fördröjning och ingen användarinteraktion. Utvecklaren behöver inte skriva komplex sammanslagningslogik och användaren ser inga versionsvalsdialoger. Priset för enkelheten är dock potentiell dataförlust, som inte alla appar har råd med.

Enligt forskning av Martin Kleppmann (författare till „Designing Data-Intensive Applications”, O’Reilly, 2024) är LWW den mest utbredda strategin i produktionssystem, som används i cirka 70 % av distribuerade applikationer där eventuell konsekvens (eventual consistency) är acceptabel. I 23 % av fallen leder det till mätbar förlust av användardata.

Hur LWW-mekanismen fungerar

LWW-mekanismen bygger på jämförelse av tidsstämplar. Varje datapost åtföljs av en timestamp som kan ställas in av klienten (client-side timestamp) eller servern (server-side timestamp). När en konflikt upptäcks jämför systemet tidsstämplarna för båda versionerna och accepterar posten med det högre värdet. Den andra versionen kasseras eller sparas i historiken för granskning.

Client-side timestamp har en nackdel: klockorna på användarnas enheter kan vara osynkroniserade. Om användare A:s telefon ligger 5 minuter efter och användare B gör ändringar kan A:s post efter klockkorrigering felaktigt anses vara nyare. Därför använder produktionssystem oftare server-side timestamp, som tilldelas av servern vid datamottagning.

LWW-logik med server-side timestamp:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

Funktionen resolveLWW tar emot två dokument och returnerar det med störst timestamp. Vid likhet vinner vanligtvis det inkommande dokumentet — detta garanterar att nya data inte går förlorade på grund av överlappande stämplar.

För- och nackdelar med Last Write Wins

Den största fördelen med LWW är algoritmisk enkelhet. Strategin kräver varken lagring av versionshistorik, analys av ändringar på fältnivå eller lösning av komplexa konflikter. Servern behandlar konflikten i en enda jämförelseoperation, vilket gör LWW till den snabbaste strategin. I Firebase Realtime Database behandlar LWW upp till 100 tusen konflikter per sekund på en enda nod.

Den största nackdelen — dataförlust vid oberoende ändringar av olika fält. Om användare A har ändrat namnet på en uppgift och användare B har ändrat beskrivningen kommer LWW att kassera en av versionerna helt, även om båda ändringarna borde ha bevarats. Detta är särskilt kritiskt för formulär, profiler och konfigurationer där varje fält har betydelse.

Jämförelse av LWW med alternativa strategier:

Exempel på LWW-implementering i Kotlin

Låt oss titta på LWW-implementeringen i kontexten av en mobil app för inköpslista där flera familjemedlemmar kan lägga till och markera produkter offline. Varje listelement lagrar ID, namn, status och tidsstämpeln för senaste uppdatering. Vid synkronisering tillämpas LWW för varje element.

Grundmodell för listelement:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

Funktionen syncWithLWW slår samman lokala och fjärrlistor: om ett element bara finns på en sida — läggs det till, om det finns på båda sidor — vinner den nyare versionen. Detta tillvägagångssätt säkerställer deterministisk synkronisering för varje enskilt element.

LWW kontra Merge: vad man ska välja

Valet mellan LWW och Merge bestäms av datamodifieringens karaktär. Om applikationen tillåter oberoende fältändringar (olika användare ändrar olika fält i samma objekt) kommer Merge Strategy att bevara data mer exakt. Om ändringarna alltid är atomära (användaren ändrar hela objektet) är LWW fullt adekvat och mycket enklare att implementera.

I praktiken tillämpar många system en hybridansats: LWW för metainformation och fält på toppnivå, Merge för strukturerad data. Firebase Firestore använder till exempel LWW för de flesta operationer men stödjer transaktioner med optimistisk låsning för atomära uppdateringar när utvecklaren explicit anger att ett fält inte får gå förlorat vid konflikt.

Enligt en undersökning bland utvecklare av distribuerade system (Stack Overflow Survey, 2025) väljer 54 % LWW för MVP och prototyper och går över till Merge eller CRDT i skalfasen. Det viktigaste kriteriet är konfliktfrekvensen: om mindre än 1 % av sessionerna leder till konflikter är LWW mer än tillräckligt. Om konflikter påverkar mer än 5 % av sessionerna är det värt att investera i Merge eller CRDT.