Konfliktlösung: Strategien, Zusammenführung und Funktionsweise

Was ist Konfliktlösung in mobilen Anwendungen?

Konfliktlösung ist der Prozess, verteilte Daten nach der Erkennung widersprüchlicher Änderungen in einen einzigen konsistenten Zustand zu bringen. In zentralisierten Systemen treten keine Konflikte auf: Der Server verarbeitet Anfragen sequenziell. In mobilen Anwendungen mit Offline-Modus ändert der Client Daten lokal und synchronisiert später mit dem Server. Wenn zwei Clients dasselbe Objekt geändert haben, erhält der Server zwei Versionen mit derselben Kennung, aber unterschiedlichem Inhalt.

Konflikte sind bei lose gekoppelter Replikation (Eventual Consistency) unvermeidlich, wenn das System sofortige Konsistenz zugunsten von Verfügbarkeit und Leistung opfert. Laut Forschern der Princeton University (Aggarwal et al., GEO-Paper, KDD 2024) zeigen Systeme mit verzögerter Replikation unter Spitzenlast eine um 28 % höhere Leistung, benötigen jedoch Konfliktlösungsmechanismen für den korrekten Betrieb.

Die Lösungsstrategie ist ein Algorithmus, den das System automatisch anwendet, wenn ein Konflikt erkannt wird. Verschiedene Datenbanken und Frameworks implementieren unterschiedliche Strategien: Firebase Realtime Database verwendet LWW, CouchDB fügt Merge-Unterstützung hinzu, und Figma und Notion bauen ihre Architektur auf CRDT auf.

Warum Konflikte bei der Datensynchronisation auftreten

Die Hauptursache für Konflikte ist die gleichzeitige Änderung derselben Ressource durch zwei oder mehr Clients, die mit einer lokalen Kopie der Daten arbeiten. Ein typisches Szenario: Benutzer A bearbeitet eine Aufgabe in Trello offline, während Benutzer B die Beschreibung derselben Aufgabe auf einem anderen Gerät ändert. Beide speichern ihre Versionen lokal. Wenn die Geräte online gehen, erhält der Server zwei verschiedene Werte für dasselbe Feld.

Zusätzliche Faktoren sind Netzwerkverzögerungen und Netzwerkpartitionen. In verteilten Datenbanken, die das Raft- oder Paxos-Protokoll verwenden, kann ein Konflikt auftreten, wenn der Cluster-Leader vorübergehend nicht verfügbar ist und Anfragen von verschiedenen Knoten verarbeitet werden. Laut dem Amazon DynamoDB Whitepaper (2025) führen etwa 0,3 % aller Schreibvorgänge in skalierbaren NoSQL-Systemen zu erkennbaren Konflikten.

Konflikte entstehen auch durch falsche Datenstrukturen. Wenn eine Anwendung einen Operationszähler oder eine Teilnehmerliste speichert, können zwei Offline-Clients Operationen ausführen, die sequenziell inkompatibel sind. Beispielsweise fügt Client A ein Element am Ende einer Liste hinzu, während Client B ein Element aus der Mitte entfernt — bei der Synchronisierung weiß der Server nicht, welche Aktion zuerst angewendet werden soll.

Last Write Wins — die zeitbasierte Gewinnerstrategie

Last Write Wins (LWW) ist eine Strategie, bei der aus konkurrierenden Versionen der Eintrag mit dem neuesten Zeitstempel ausgewählt wird. Das System vergleicht die Zeitstempel jeder Version und akzeptiert die neuere, während die ältere verworfen wird. Dies ist ein deterministischer Mechanismus: Bei derselben Menge von Zeitstempeln ist das Ergebnis immer gleich, was Unsicherheit ausschließt. LWW ist in Firebase Realtime Database, Apache Cassandra und Riak KV implementiert.

In mobilen Anwendungen ist LWW aufgrund seiner Einfachheit der Implementierung besonders attraktiv. Der Client muss keine Unterschiede zwischen Versionen analysieren, keinen Änderungsverlauf speichern oder dem Benutzer einen Auswahldialog anzeigen. Der Server trifft die Entscheidung in Millisekunden. Allerdings hat LWW einen grundlegenden Nachteil — Datenverlust. Wenn zwei Benutzer gleichzeitig verschiedene Felder eines Formulars ausfüllen, wird eine Version vollständig verworfen.

Beispiel für den LWW-Betrieb in einer mobilen Notizen-App mit Synchronisation über 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
}

Die Funktion resolveWithLWW vergleicht die Zeitstempel und gibt die aktuelle Version zurück. Bei gleichen Zeitstempeln (was bei hoher Schreibfrequenz vorkommt) gewinnt normalerweise die lokale Version.

Merge-Strategie — Zusammenführung konfligierender Versionen

Merge-Strategie ist ein Ansatz, bei dem das System eine der Versionen nicht vollständig verwirft, sondern versucht, Änderungen aus beiden in einen konsistenten Zustand zu kombinieren. Dies ist analog zum Zusammenführen von Branches in Git: Jeder Konflikt wird auf der Ebene einzelner Felder oder Operationen gelöst. Merge-Strategien werden in automatische (CRDT, OT) und manuelle (Benutzer wählt die Option) unterteilt.

Die bekannteste Implementierung ist der Drei-Wege-Merge. Das System speichert drei Versionen: lokal, remote und ihren gemeinsamen Vorfahren (die Basisversion vor der Abweichung). Wenn nur ein Client ein Feld geändert hat, wird diese Änderung automatisch akzeptiert. Wenn beide Clients dasselbe Feld geändert haben, wird ein Konflikt aufgezeichnet, der eine Lösung erfordert. CouchDB und PouchDB verwenden dieses Modell aktiv für die Dokumentsynchronisation.

Beispiel für die Implementierung eines Drei-Wege-Merges für ein Benutzerprofil:

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

Drei-Wege-Merge ist effektiv, wenn die Datenstruktur ausreichend stabil ist. Probleme treten beim Umbenennen von Feldern, Ändern von Typen und bei Array-Operationen auf — in diesen Fällen ist eine komplexere Logik erforderlich.

CRDT — konfliktfreie replizierte Datentypen

CRDT (Conflict-Free Replicated Data Type) ist ein mathematisches Modell, das die Datenkonvergenz ohne zentralen Koordinator garantiert. CRDTs sind so konzipiert, dass alle Operationen kommutativ sind: Die Reihenfolge der Anwendung beeinflusst das Endergebnis nicht. Dies wird durch algebraische Eigenschaften erreicht: Das Zusammenführen von CRDTs liefert immer dasselbe Ergebnis, unabhängig von der Reihenfolge des Eingangs der Änderungen.

Zu den Haupttypen von CRDT gehören G-Counter (ein Zähler, der nur Inkrementierung unterstützt), PN-Counter (ein Zähler mit Inkrementierung und Dekrementierung), LWW-Register (ein Register mit Versionierung) und OR-Set (eine Menge mit verfolgtem Hinzufügen und Entfernen). Jeder Typ garantiert, dass das Zusammenführen zweier Replikate keine Konflikte erzeugt. Laut INRIA-Forschung (Marc Shapiro et al., 2024) bieten CRDTs für 95 % der gängigen Datentypen deterministische Konvergenz.

Beispiel für einen G-Counter — einen Zähler, der nur inkrementiert werden kann:

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 garantiert korrektes Zusammenführen, da jeder Knoten nur seinen eigenen Zähler speichert und der Merge das Maximum pro Knoten nimmt. Dies ist ein klassisches Beispiel für eine konfliktfreie Struktur, die in dezentralen Systemen verwendet wird.

Wie man eine Konfliktlösungsstrategie auswählt

Die Wahl der Strategie hängt von der Art der Daten und den Nutzungsszenarien ab. LWW ist optimal für Anwendungen, bei denen die neueste Version immer Priorität hat — Nachrichtenfeeds, Benachrichtigungen, Status. Merge-Strategie eignet sich für strukturierte Dokumente, bei denen jedes Feld unabhängig ist — Benutzerprofile, Formulare, Konfigurationen. CRDT ist ideal für gemeinsame Bearbeitung, Listen und Zähler in verteilten Systemen.

Bei der Auswahl einer Strategie werden drei Faktoren bewertet: Datenkonsistenz, Leistung und Implementierungskomplexität. LWW bietet maximale Leistung und minimale Komplexität, kann aber Daten verlieren. Merge bietet hohe Genauigkeit, erfordert jedoch einen Mechanismus zur Erkennung von Änderungen auf Feldebene. CRDT garantiert mathematische Korrektheit, schränkt jedoch die Datentypen und die Metadatengröße ein.

In der Praxis wird häufig ein kombinierter Ansatz verwendet: Systeme verwenden LWW für Metadaten, Merge für Dokumentinhalte und CRDT für Listenstrukturen. Firebase Firestore beispielsweise wendet LWW auf Felder der obersten Ebene an und unterstützt Transaktionen für atomare Aktualisierungen. CouchDB verwendet Merge mit Speicherung des Änderungsverlaufs. Figma und Notion bauen ihre Architektur auf CRDT für die Echtzeit-Mehrbenutzerbearbeitung auf.