CRDT (Conflict-free Replicated Data Type)

• Redis Enterprise: Nutzt CRDTs für Geo-Replication (Active-Active).
• Local-First Software: Tools wie Joplin oder Muse nutzen CRDTs, damit du offline arbeiten kannst.
• Yjs / Automerge: JavaScript Libraries, um collaborative Apps zu bauen (Co-Editing wie in Google Docs, aber dezentral).

1. CvRDT vs CmRDT

• CvRDT (State-based): Sende den ganzen Zustand (oder Delta). Merge Funktion muss kommutativ, assoziativ und idempotent sein (Join-Semilattice).
• CmRDT (Operation-based): Sende die Operation ("add 5"). Setzt zuverlässiges Messaging voraus (Exactly-Once delivery). Meistens komplexer.

2. Tombstones

Problem bei Sets: Löschen. Wenn ich "X" lösche, und du "X" hinzufügst - wer gewinnt? Oder wenn ich "X" lösche, aber das "Lösch-Event" kommt später als ein altes "Create-Event"? Lösung: Wir löschen nicht. Wir fügen "X" zu einem "Tombstone-Set" (Friedhof) hinzu. Ein Element ist im Set, wenn es in Additions ist UND NICHT in Removals. Nachteil: Speicherleck (Garbage Collection von Tombstones ist schwer).

1. CvRDT (State-based) vs. CmRDT (Op-based)

Mathematisch gibt es zwei Spezies von Conflict-free Replicated Data Types, die auf unterschiedliche Netzwerk-Gegebenheiten getrimmt sind. CvRDT (Convergent / State-based): Ein Node sendet konsequent sein generelles Daten-Delta an Peers. Voraussetzung für die Konfliktfreiheit ist, dass zwei Status an jeder Empfangsnode mittels Join-Semilattice zusammengeführt werden (eine Operation, die per Definition strikt kommutativ, assoziativ und idempotent ist). Droppt ein Netzwerkpaket, überträgt man den kompletten Status beim Re-Connect und repariert das System fehlerfrei. CmRDT (Commutative / Op-based): Knoten replizieren pure Operationen (add 5). Hier reicht Kommutativität zwingend aus, aber der Message-Bus verlangt blutigen Ernst in der Infrastruktur: Operationen müssen exactly-once und manchmal noch causally-ordered einlaufen, sonst rechnet Node B add 5, empfängt es nochmal und wächst verheerend ins Unendliche hinein.

2. Sequence CRDTs (RGA für Text-Editing)

Wenn zwei User auf Netflix kollaborieren, adden sie nicht nur in Sets, sie tippen Fließtext. Wo landet ein Buchstabe, wenn User 1 und 2 den exakt gleichen Offset des Dokuments abändern? Dies lösen Sequence CRDTs (wie Replicated Growable Array, RGA, eingebaut in Yjs). Sie indizieren nicht starr nach Charakter-Position (Index 5). Sie knüpfen Zeichen als asynchrone Linked-List. Jedes getippte "a" bekommt eine unique Timestamp/Node-ID und eine harte Referenz: "Ich wurde eilig rechts von Buchstabe XYZ eingefügt". Trifft im Cluster nun Konflikt-Gleichzeitigkeit auf, evaluieren feste Tie-Breaker die Priorität, und der Text fügt sich verlässlich, egal in welchem Kontinent die Clients ihren DOM-Tree gerade parsen.

3. Tombstone Garbage Collection

Der Endgegner beim Programmieren tiefer CRDTs in Production. Mathematische CRDTs dürfen strenggenommen niemals Daten zerstören, sonst greift Synchronisation inkrementell unsichtbar ins Leere (Wer hat "X" gelöscht vs. Wurde "X" gerade erst kreiert?). Statt Element "X" brutal zu deallozierten, maskieren ihn Marker als Tombstone. Langfristig wird eine Co-Editing Session dadurch zu einem gigantischen Friedhof unsichtbarer Artefakte (Speicherleak im RAM). Aktuelle Research-Engines fokussieren massive Engineering-Leistung auf Garbage Collection Epochs. Sind sich alle Online-Teilnehmer (des Causal Graphs) einig, dass Tombstone B garantiert bei 100% aller Replikate gesehen wurde, wird dieser Konsens zementiert und das Phantom restlos gekürzt.