Weak Consistency (schwache Konsistenz) ist der Sammelbegriff für alle Konsistenzmodelle, die nicht garantieren, dass ein Lesezugriff unmittelbar nach einem Schreibzugriff den neuen Wert liefert. Werner Vogels, CTO von Amazon, prägte die Einteilung in seinem Aufsatz Eventually Consistent (ACM Queue, 2008): Während Strong Consistency dafür sorgt, dass jede spätere Leseoperation den letzten Schreibvorgang sieht, verlangt Weak Consistency diese Zusicherung nicht — es kann Bedingungen geben, die erst erfüllt sein müssen, bevor der neue Wert sichtbar wird.
Das Konsistenzspektrum
Zwischen den beiden Extremen liegt ein ganzes Spektrum an Modellen. Vereinfacht von stark nach schwach:
- Strong Consistency (Linearisierbarkeit): jede Leseoperation liefert den neuesten Wert, als gäbe es nur eine einzige Kopie der Daten.
- Kausale Konsistenz: kausal zusammenhängende Operationen (Ursache vor Wirkung) erscheinen überall in derselben Reihenfolge — Kausale Konsistenz ist das stärkste Modell, das bei Netzwerkpartitionen noch verfügbar bleibt.
- Session-Garantien: Read-Your-Writes, Monotonic Reads, Writes Follow Reads und Monotonic Writes sichern einzelne Sitzungen ab.
- Eventual Consistency: wenn keine neuen Schreibvorgänge mehr eintreffen, konvergieren alle Repliken schließlich auf denselben Wert — Eventual Consistency ist der bekannteste Spezialfall der schwachen Konsistenz.
Weak vs. Eventual
Der Unterschied liegt in der Garantie: Weak Consistency verspricht grundsätzlich keine Sichtbarkeitsregel — ein Lesezugriff kann beliebig lange einen veralteten Wert liefern. Eventual Consistency ist eine stärkere Zusage innerhalb des schwachen Spektrums: Sie verlangt, dass sich die Repliken irgendwann angleichen, sobald die Schreibvorgänge aufhören. In der Praxis nähert sich der Sprachgebrauch an: Wenn Systeme „schwache Konsistenz" anbieten, meinen sie meist Eventual Consistency, weil ein Modell ganz ohne Konvergenz für Anwendungen kaum brauchbar wäre.
Warum schwache Konsistenz?
Starke Konsistenz kostet Latenz: Jeder Schreibvorgang muss mit einem Quorum von Replikaten abstimmen und blockiert bei Netzwerkproblemen. Schwache Modelle erlauben es, Schreibvorgänge lokal zu beantworten und Updates asynchron zu verbreiten — genau das brauchen global skalierende Systeme wie soziale Netzwerke, Warenkörbe oder Content-Delivery-Netze. Das CAP-Theorem formalisiert diesen Konflikt: Bei einer Partition muss ein System zwischen Konsistenz und Verfügbarkeit wählen. Wer schnelle Antworten und Hochverfügbarkeit will, landet unweigerlich auf der schwachen Seite des Spektrums.
Verwandte Begriffe
Zusammenhängende Grundlagen finden Sie unter Verteilte Systeme, Quorum, Hochverfügbarkeit sowie in den Datenbank-Artikeln Sharding und Datenbank-Replikation.