Last Write Wins: Was es ist, Mechanismus und Funktionsprinzip

Was ist Last Write Wins in der mobilen Entwicklung?

Last Write Wins (LWW) ist eine Strategie des letzten Schreibens zur Lösung von Synchronisationskonflikten. Wenn zwei Clients dasselbe Datenobjekt ändern, empfängt der Server beide Versionen und wählt die mit dem größeren Zeitstempel aus. LWW ist die Standardstrategie in vielen verteilten Systemen: Firebase Realtime Database, Apache Cassandra, Riak KV und DynamoDB im Modus des letzten Schreibens.

In mobilen Anwendungen ist LWW aus drei Gründen attraktiv: Einfachheit der Implementierung, minimale Latenz und keine Benutzerinteraktion erforderlich. Der Entwickler muss keine komplexe Mergelogik schreiben und der Benutzer sieht keine Dialoge zur Versionsauswahl. Der Preis für die Einfachheit ist jedoch der potenzielle Datenverlust — den nicht alle Anwendungen verkraften können.

Laut einer Studie von Martin Kleppmann (Autor von „Designing Data-Intensive Applications“, O’Reilly, 2024) ist LWW die häufigste Strategie in Produktionssystemen und wird in etwa 70% der verteilten Anwendungen verwendet, bei denen Eventual Consistency akzeptabel ist. In 23% der Fälle führt sie zu einem messbaren Verlust von Benutzerdaten.

Wie der LWW-Mechanismus funktioniert

Der LWW-Mechanismus basiert auf dem Vergleich von Zeitstempeln. Jeder Datensatz wird von einem Zeitstempel begleitet, der vom Client (Client-seitiger Zeitstempel) oder vom Server (Server-seitiger Zeitstempel) gesetzt werden kann. Bei Erkennung eines Konflikts vergleicht das System die Zeitstempel beider Versionen und akzeptiert den Datensatz mit dem größeren Wert. Die zweite Version wird entweder verworfen oder für die Prüfung im Verlauf gespeichert.

Der Client-seitige Zeitstempel hat einen Nachteil: Die Uhren auf den Geräten der Benutzer können asynchron sein. Wenn das Telefon von Benutzer A 5 Minuten nachgeht und Benutzer B Änderungen vorgenommen hat, könnte der Datensatz von A nach der Uhrenkorrektur fälschlicherweise als neuer angesehen werden. Daher verwenden Produktionssysteme häufiger Server-seitige Zeitstempel, die vom Server beim Empfang der Daten vergeben werden.

LWW-Logik mit Server-seitigem Zeitstempel:

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
}

Die Funktion resolveLWW nimmt zwei Dokumente entgegen und gibt das mit dem größeren Zeitstempel zurück. Bei Gleichheit gewinnt in der Regel das eingehende Dokument — dies stellt sicher, dass neue Daten aufgrund übereinstimmender Zeitstempel nicht verloren gehen.

Vor- und Nachteile von Last Write Wins

Der Hauptvorteil von LWW ist die algorithmische Einfachheit. Die Strategie erfordert keine Speicherung des Versionsverlaufs, keine Analyse von Änderungen auf Feldebene und keine Lösung zusammengesetzter Konflikte. Der Server behandelt einen Konflikt mit einer einzigen Vergleichsoperation, was LWW zur schnellsten Strategie macht. In Firebase Realtime Database verarbeitet LWW bis zu 100.000 Konflikte pro Sekunde auf einem einzigen Knoten.

Der Hauptnachteil ist der Datenverlust bei unabhängigen Änderungen an verschiedenen Feldern. Wenn Benutzer A den Aufgabennamen geändert hat und Benutzer B die Beschreibung, verwirft LWW eine Version vollständig, obwohl beide Änderungen erhalten bleiben sollten. Dies ist besonders kritisch für Formulare, Profile und Konfigurationen, bei denen jedes Feld von Bedeutung ist.

Vergleich von LWW mit alternativen Strategien:

Beispiele für die LWW-Implementierung in Kotlin

Betrachten wir eine LWW-Implementierung im Kontext einer mobilen Einkaufslisten-App, bei der mehrere Familienmitglieder offline Artikel hinzufügen und markieren können. Jeder Listeneintrag speichert eine ID, Name, Status und den Zeitstempel der letzten Aktualisierung. Während der Synchronisation wird LWW auf jeden Eintrag angewendet.

Basis-Modell eines Listeneintrags:

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
}

Die Funktion syncWithLWW führt lokale und entfernte Listen zusammen: Wenn ein Element nur auf einer Seite existiert, wird es hinzugefügt; wenn auf beiden Seiten vorhanden, gewinnt die neuere Version. Dieser Ansatz gewährleistet eine deterministische Synchronisation für jeden einzelnen Eintrag.

LWW vs. Merge: Was wählen

Die Wahl zwischen LWW und Merge wird durch die Art der Datenänderung bestimmt. Wenn die Anwendung unabhängige Feldänderungen zulässt (verschiedene Benutzer ändern verschiedene Felder desselben Objekts), bewahrt die Merge Strategy Daten genauer. Wenn Änderungen immer atomar sind (ein Benutzer ändert das gesamte Objekt), ist LWW völlig ausreichend und wesentlich einfacher zu implementieren.

In der Praxis verwenden viele Systeme einen hybriden Ansatz: LWW für Metainformationen und Felder der oberen Ebene, Merge für strukturierte Daten. Firebase Firestore beispielsweise verwendet LWW für die meisten Operationen, unterstützt aber Transaktionen mit optimistischem Sperren für atomare Aktualisierungen, wenn der Entwickler explizit angibt, dass ein Feld bei einem Konflikt nicht verloren gehen darf.

Laut einer Umfrage unter Entwicklern verteilter Systeme (Stack Overflow Survey, 2025) wählen 54% LWW für MVPs und Prototypen und wechseln beim Skalieren zu Merge oder CRDT. Das entscheidende Kriterium ist die Konflikthäufigkeit: Wenn weniger als 1% der Sitzungen zu Konflikten führen, ist LWW mehr als ausreichend. Wenn Konflikte mehr als 5% der Sitzungen betreffen, lohnt sich eine Investition in Merge oder CRDT.