Last Write Wins: wat is het, mechanisme en werkingsprincipe

Wat is Last Write Wins in mobiele ontwikkeling?

Last Write Wins (LWW) — is de strategie van laatste schrijven bij het oplossen van synchronisatieconflicten. Wanneer twee clients hetzelfde gegevensobject wijzigen, ontvangt de server beide versies en kiest degene met de grotere tijdsstempel (timestamp). LWW is de standaardstrategie in veel gedistribueerde systemen: Firebase Realtime Database, Apache Cassandra, Riak KV en DynamoDB in de laatste-schrijfmodus.

In mobiele apps is LWW om drie redenen aantrekkelijk: eenvoud van implementatie, minimale vertraging en geen gebruikersinteractie. De ontwikkelaar hoeft geen complexe samenvoeglogica te schrijven en de gebruiker ziet geen versiekeuzedialogen. De prijs voor eenvoud is echter potentieel gegevensverlies, dat niet alle apps zich kunnen veroorloven.

Volgens onderzoek van Martin Kleppmann (auteur van „Designing Data-Intensive Applications”, O’Reilly, 2024), is LWW de meest wijdverbreide strategie in productiesystemen, gebruikt in ongeveer 70% van de gedistribueerde applicaties waar eventual consistency aanvaardbaar is. In 23% van de gevallen leidt dit tot meetbaar gegevensverlies van gebruikers.

Hoe werkt het LWW-mechanisme

Het LWW-mechanisme is gebaseerd op het vergelijken van tijdsstempels. Elk gegevensrecord gaat vergezeld van een timestamp die door de client (client-side timestamp) of door de server (server-side timestamp) kan worden ingesteld. Bij detectie van een conflict vergelijkt het systeem de timestamps van beide versies en accepteert het record met de hoogste waarde. De tweede versie wordt ofwel weggegooid of in de geschiedenis bewaard voor audit.

Client-side timestamp heeft een nadeel: de klokken op de apparaten van gebruikers kunnen gedesynchroniseerd zijn. Als de telefoon van gebruiker A 5 minuten achterloopt en gebruiker B wijzigingen aanbrengt, kan het record van A na correctie van de klok ten onrechte als nieuwer worden beschouwd. Daarom gebruiken productiesystemen vaker server-side timestamp, toegewezen door de server bij ontvangst van gegevens.

LWW-logica met 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
}

De functie resolveLWW ontvangt twee documenten en retourneert degene met de grootste timestamp. Bij gelijkheid wint meestal het inkomende document — dit garandeert dat nieuwe gegevens niet verloren gaan door overlapping van stempels.

Voor- en nadelen van Last Write Wins

Het belangrijkste voordeel van LWW is algoritmische eenvoud. De strategie vereist geen opslag van versiegeschiedenis, analyse van wijzigingen op veldniveau of het oplossen van complexe conflicten. De server verwerkt het conflict in een enkele vergelijkingsoperatie, wat LWW de snelste strategie maakt. In Firebase Realtime Database verwerkt LWW tot 100 duizend conflicten per seconde op een enkel knooppunt.

Het grootste nadeel — gegevensverlies bij onafhankelijke wijzigingen van verschillende velden. Als gebruiker A de naam van een taak heeft gewijzigd en gebruiker B de beschrijving, zal LWW een van de versies volledig weggooien, hoewel beide wijzigingen behouden hadden moeten blijven. Dit is vooral kritiek voor formulieren, profielen en configuraties waar elk veld van belang is.

Vergelijking van LWW met alternatieve strategieën:

Voorbeelden van LWW-implementatie in Kotlin

Laten we de LWW-implementatie bekijken in de context van een mobiele boodschappenlijst-app waar meerdere gezinsleden offline producten kunnen toevoegen en markeren. Elk lijstelement slaat ID, naam, status en de tijdsstempel van de laatste update op. Bij synchronisatie wordt LWW toegepast voor elk element.

Basis model van een lijstelement:

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
}

De functie syncWithLWW voegt lokale en externe lijsten samen: als een element slechts aan een kant bestaat — wordt het toegevoegd, als aan beide kanten — wint de nieuwere versie. Deze benadering zorgt voor deterministische synchronisatie voor elk afzonderlijk element.

LWW versus Merge: wat te kiezen

De keuze tussen LWW en Merge wordt bepaald door de aard van gegevenswijziging. Als de applicatie onafhankelijke veldwijzigingen toestaat (verschillende gebruikers wijzigen verschillende velden van hetzelfde object), zal Merge Strategy gegevens nauwkeuriger behouden. Als wijzigingen altijd atomair zijn (de gebruiker wijzigt het hele object), is LWW volledig adequaat en veel eenvoudiger te implementeren.

In de praktijk passen veel systemen een hybride aanpak toe: LWW voor meta-informatie en velden op topniveau, Merge voor gestructureerde gegevens. Firebase Firestore gebruikt bijvoorbeeld LWW voor de meeste bewerkingen, maar ondersteunt transacties met optimistische vergrendeling voor atomaire updates wanneer de ontwikkelaar expliciet aangeeft dat een veld niet verloren mag gaan bij een conflict.

Volgens een enquête onder ontwikkelaars van gedistribueerde systemen (Stack Overflow Survey, 2025), kiest 54% LWW voor MVP en prototypes, en stapt over op Merge of CRDT in de schaalfase. Het belangrijkste criterium is de conflictfrequentie: als minder dan 1% van de sessies tot conflicten leidt, is LWW meer dan voldoende. Als conflicten meer dan 5% van de sessies beïnvloeden, is het de moeite waard om te investeren in Merge of CRDT.