Causal Consistency

Noch schwächer als Sequential, aber stärker als Eventual. Es respektiert Ursache und Wirkung. Beispiel Chat: Alice fragt: "Gehen wir essen?" (Nachricht A). Bob antwortet: "Ja, Burger!" (Nachricht B). Wenn Charlie Nachricht B ("Ja, Burger!") sieht, muss er davor schon A gesehen haben. Warum? Weil B eine Antwort auf A ist. B ist kausal abhängig von A. Wenn Charlie aber erst B sieht ("Ja, Burger!"), denkt er: "Hä? Worauf antwortet der?". Unabhängige Events (Dora postet: "Es regnet") dürfen in beliebiger Reihenfolge ankommen. Das ist das perfekte Modell für Chat-Apps, Kommentare und Social Media.

Merksatz: Ein Konsistenzmodell, das garantiert, dass kausal zusammenhängende Ereignisse (Ursache vor Wirkung) bei allen Teilnehmern in der gleichen Reihenfolge gesehen werden, während unabhängige Ereignisse unterschiedlich geordnet sein können.

COPS / Eiger: Akademische Datenbanken, die das implementieren.
MongoDB: Bietet "Causal Consistency" in Client Sessions. "Wenn ich einen Write mache, müssen alle meine folgenden Reads diesen Write sehen (Read-your-Writes) und alles, was daraus folgt."
React/Redux: Nicht direkt Datenbank, aber im Frontend State Management wichtig. "Zeige den Kommentar erst an, wenn der Post geladen ist."

1. Vector Clocks

Um Kausalität zu tracken, braucht man Vector Clocks. Jede Nachricht bekommt einen Vektor [v1, v2, v3]. Wenn V_msg > V_local, dann fehlt uns was -> Warten (Puffern). Das ist "billig" (kein globaler Koordinator nötig), aber die Metadaten (Vektoren) können groß werden.

2. The Strongest Available

Ein wichtiges Theorem beweist: Causal Consistency ist das stärkste Modell, das noch "Available" (AP) sein kann. Linearizability und Sequential Consistency erfordern CP (sind nicht verfügbar bei Partition). Causal ist das Limit ("The Sweet Spot").

1. Kausale Graphen & Metadaten-Explosion

Technisch wird Kausalität oft als Graph (DAG - Directed Acyclic Graph) dargestellt. Jedes Update speichert eine Liste von IDs seiner "Eltern-Updates". Ein Problem in der Produktion ist die Metadaten-Größe. Wenn ein Dokument von 1000 Usern bearbeitet wird, muss jedes neue Update theoretisch 1000 IDs mitschleppen, um die Kausalität zu beweisen. Systeme wie Eiger nutzen daher Causal Context Trimming. Man trackt nicht jedes einzelne Event, sondern nur "Checkpoints" oder nutzt Dotted Version Vectors, um die Vektoren kompakt zu halten. Trotzdem bleibt Causal Consistency bei Millionen von Objekten ein administrativer Albtraum für die Storage-Engine.

2. Write-Read Dependencies vs. Read-Modify-Write

Causal Consistency unterscheidet mehrere Ebenen:

Read-your-Writes: Ich sehe immer, was ich selbst gerade geändert habe.
Monotonic Reads: Wenn ich einmal Version 2 gesehen habe, darf ich niemals wieder Version 1 sehen.
Writes-follow-Reads: Wenn ich Nachricht A lese und daraufhin B poste, darf niemand B sehen, ohne A zu kennen. Das klingt logisch, ist aber in einer weltweit verteilten Datenbank (Edge Computing) extrem schwer zu garantieren, da Nachrichten über verschiedene Seekabel mit unterschiedlichen Latenzen reisen.

3. Causal + Strong (Causal+)

Da Causal Consistency alleine keine Konflikte löst (was passiert, wenn zwei Leute gleichzeitig das Gleiche ändern?), nutzt man oft Causal+. Dies kombiniert Kausalität mit einer Deterministic Conflict Resolution (z. B. "Last Writer Wins" oder CRDTs - Conflict-free Replicated Data Types). Causal+ ist das "heilige Blech" für Offline-First Apps (wie Google Docs oder Trello). Es fühlt sich lokal so schnell an wie Sequential, funktioniert aber auch ohne Internetverbindung weiter und führt die Änderungen später logisch korrekt wieder zusammen.