Notion ersetzt Last-Write-Wins im Block durch eine RGA-CRDT
Victoria Shinder2 Min. LesezeitNotion hat veröffentlicht, wie sein Editor aufgehört hat, Text zu verlieren. Der Technikbeitrag steht unter https://www.notion.com/blog/how-notion-handles-concurrent-editing-with-crdts, und das Eingeständnis gleich zu Beginn ist der interessante Teil: bis 2025 war das Produkt nicht wirklich kollaborativ — in dem genauen Sinn, dass zwei Personen im selben Block eine der beiden Änderungen verlieren konnten.
Das alte Verhalten war Last Write Wins auf dem Blockdatensatz. Zwei gleichzeitige Aktualisierungen erreichten den Server, jede ohne Kenntnis der anderen, und die zweite wurde zur Wahrheit. Warum das nicht ständig auffiel, liegt an der Struktur: Eine Notion-Seite besteht aus vielen Blöcken, jeder ein eigener Datenbankeintrag — wer verschiedene Absätze bearbeitete, kollidierte nie. Die Kollision passierte nur innerhalb eines Blocks, und je mehr Mitschreibende, desto wahrscheinlicher.
Erzwungen hat die Lösung der Offline-Modus. Wer eine Seite ohne Verbindung bearbeitete, konnte alles Geschriebene verlieren, falls andere dieselben Blöcke anfassten, bevor er zurückkam. Eine Warteschlange von Änderungen, abgespielt gegen einen Last-Write-Wins-Speicher, ist eine Maschine zur Datenvernichtung.
Die Lösung ist eine Sequenz-CRDT auf Basis des Replicated Growable Array. Jedes je eingefügte Zeichen ist ein Knoten in einem Baum mit stabiler, eindeutiger Kennung; Notion nennt die Knoten Text-Items und die referenzierten Kennungen Origins. Einfüge- und Löschoperationen zeigen auf diese Kennungen, nicht auf Positionen. Gelöscht wird dabei nichts: Das Element wird als Tombstone markiert, denn noch laufende — oder auf einem Offline-Client liegende — Operationen können sich auf Kennungen bereits entfernter Zeichen beziehen, und ohne sie gäbe es keinen Ort, an dem sie anzuwenden wären.
Der Beitrag benennt die Grenze offen: verlustfrei zusammenführen ist nicht dasselbe wie Absicht bewahren. Schreiben zwei Personen dieselbe Passage um, behält die Fusion beide Änderungen und keinen der beiden Sätze. Tragbar ist das vor allem deshalb, weil in einem langen Dokument meist an verschiedenen Stellen gearbeitet wird.
Was das bedeutet
Ein Datenmodell kann einen Korrektheitsfehler jahrelang verdecken — und dann legt ihn eine Funktion frei. Ein Datensatz je Block ließ gleichzeitiges Schreiben in Ordnung aussehen, während die Fusionsstrategie darunter lautete: Der Text des Verlierers wird verworfen. An der Beobachtung war nichts falsch — Seitenänderungen wurden wirklich zusammengeführt — sie maß nur die falsche Einheit. Der Offline-Modus hat den Fehler nicht eingeführt, er hat die Abdeckung entfernt.
Tombstones sind der Preis referenzieller Integrität, und sie bleiben. Sobald Operationen Zeichenkennungen referenzieren, lassen sich Zeichen nicht mehr löschen, nur markieren. Jedes CRDT-Textdokument wächst daher mit der Bearbeitung, nicht mit dem Inhalt — und jedes Team, das eines ausliefert, baut irgendwann Kompaktierung. Das sollte man vor der Wahl der Struktur wissen, nicht danach.
Und „kein Datenverlust" verspricht weniger, als es klingt. Eine CRDT garantiert, dass alle Operationen überleben und alle Repliken konvergieren. Sie garantiert nicht, dass das Ergebnis ein Satz ist, den jemand geschrieben hat. Notion sagt das ausdrücklich — mehr, als die meisten Darstellungen dieser Technik zustande bringen.