Konsistenz und das CAP-Theorem

Sobald Daten auf mehr als einem Server liegen – als Replikat, in einem Cache, in einem Suchindex oder in einer anderen Region –, stellt sich eine grundsätzliche Frage: Sehen alle Teile des Systems immer denselben Stand? Und was passiert, wenn die Verbindung zwischen ihnen ausfällt? Das CAP-Theorem ist die bekannteste Antwort auf diese Frage. Es wird allerdings oft falsch verstanden. Diese Lektion erklärt, was es wirklich aussagt und wie man daraus praktische Entscheidungen ableitet.

1. Das CAP-Theorem

Das häufigste Missverständnis lautet: „Man kann sich zwei von drei aussuchen.“ Das stimmt so nicht. Netzwerkpartitionen – also Situationen, in denen Teile des Systems sich nicht mehr erreichen – passieren in verteilten Systemen einfach, man kann sie nicht wegwählen. Die eigentliche Aussage ist: Wenn eine Partition auftritt, muss das System entscheiden, ob es lieber Anfragen ablehnt, um korrekt zu bleiben, oder lieber antwortet, auch wenn die Antwort veraltet sein könnte. Probieren Sie es aus:

2. PACELC: auch ohne Ausfall eine Abwägung

Das CAP-Theorem betrachtet nur den Ausnahmefall einer Partition. Daniel Abadi hat es 2012 um eine wichtige Beobachtung erweitert, die unter dem Namen PACELC bekannt ist: Auch im Normalbetrieb, also ohne Partition (Else), muss ein verteiltes System zwischen Latenz (L) und Konsistenz (C) abwägen. Wer bei jedem Schreibvorgang wartet, bis alle Replikate bestätigt haben, ist konsistent, aber langsamer. Wer sofort bestätigt, ist schnell, aber Replikate hinken kurz hinterher. Diese Abwägung betrifft jedes System mit Replikaten, Caches oder mehreren Regionen – also fast jedes produktive System – jeden Tag, nicht nur bei seltenen Ausfällen.

3. Konsistenz gezielt wählen

Die wichtigste Erkenntnis für den Systementwurf lautet: Konsistenz ist keine Eigenschaft des ganzen Systems, sondern eine Entscheidung pro Datum und pro Vorgang. Dieselbe Anwendung kann für Zahlungen starke Konsistenz verlangen und für Like-Zähler mit zeitverzögerter Konsistenz leben. Genau das macht moderne Systeme effizient. Üben Sie die Zuordnung:

4. Muster aus der Praxis

Im Alltag begegnen diese Überlegungen in vielen Formen. Ein Onlineshop zeigt den Lagerbestand auf der Produktseite aus dem Cache, der einige Sekunden alt sein darf, prüft ihn aber beim Bezahlen stark konsistent gegen die Datenbank. Ein soziales Netzwerk zeigt Kommentare mit leichter Verzögerung, sorgt aber dafür, dass der eigene Kommentar sofort sichtbar ist. Ein Buchungssystem verwendet für die Anzeige freier Termine ein Lesereplikat, für die eigentliche Buchung den Primärserver mit einer eindeutigen Regel. Und eine Berechtigungsänderung wird sofort wirksam, indem der betroffene Cache-Eintrag gezielt gelöscht wird.

Hinzu kommt die Frage, wie man mit Konflikten umgeht, wenn zeitverzögerte Kopien unabhängig voneinander geändert wurden – etwa bei Apps, die offline funktionieren. Einfache Strategien wie „der letzte Schreibvorgang gewinnt“ sind leicht umzusetzen, können aber Änderungen verlieren. Aufwendigere Verfahren wie konfliktfreie replizierte Datentypen (CRDTs) führen Änderungen automatisch zusammen. Das Modul Moderne Anwendungsmuster vertieft dieses Thema bei der Offline-Synchronisierung.

5. Was das für den Entwurf bedeutet

Für den Systementwurf ergeben sich klare Regeln. Erstens: Identifizieren Sie die Daten, die stark konsistent sein müssen – meist diejenigen, die an Invarianten, Geld oder Berechtigungen hängen. Sie gehören in eine Datenbank mit Transaktionen und werden bei kritischen Vorgängen vom Primärserver gelesen. Zweitens: Erlauben Sie für alles andere bewusst zeitverzögerte Konsistenz und nutzen Sie die gewonnene Freiheit für Caches, Replikate und asynchrone Verarbeitung. Drittens: Machen Sie Verzögerungen für Nutzer verständlich, etwa mit Hinweisen wie „Änderungen können einige Sekunden dauern“, und sorgen Sie dafür, dass Nutzer ihre eigenen Änderungen sofort sehen. Viertens: Dokumentieren Sie diese Entscheidungen, damit spätere Änderungen nicht versehentlich eine kritische Stelle auf ein Replikat oder einen Cache umlenken.

In Vorstellungsgesprächen ist das CAP-Theorem ein beliebtes Thema. Überzeugend ist nicht, das Akronym aufzusagen, sondern an einem konkreten System zu erklären, welche Daten welche Konsistenz brauchen und warum. Wer sagt: „Für Zahlungen wähle ich Konsistenz und nehme in Kauf, dass bei einer Partition Zahlungen kurz nicht möglich sind; für den Produktkatalog wähle ich Verfügbarkeit und nehme veraltete Preise in der Anzeige in Kauf, die beim Bezahlen korrigiert werden“, zeigt genau das Verständnis, auf das es ankommt.

Ein Beispiel verdeutlicht die Denkweise. Eine Plattform für Kursbuchungen läuft in einer Region mit einem Primärserver und zwei Replikaten. Die Kursübersicht liest von den Replikaten und zeigt freie Plätze, die bis zu einer Sekunde alt sein können. Die eigentliche Buchung liest und schreibt ausschließlich auf dem Primärserver und sichert die Platzzahl mit einer atomaren Aktualisierung ab. Fällt die Verbindung zu einem Replikat aus, wird es aus dem Lesebetrieb genommen, und die Übersicht läuft über das andere weiter. Fällt der Primärserver aus, übernimmt nach wenigen Sekunden ein Replikat; in dieser Zeit sind Buchungen nicht möglich, die Übersicht aber schon. Das System wählt also für Buchungen Konsistenz und für die Anzeige Verfügbarkeit – eine bewusste, dokumentierte Entscheidung, die sich direkt aus den Anforderungen ergibt.

Wichtig ist dabei, Konsistenz nicht nur technisch, sondern auch aus Sicht der Nutzer zu betrachten. Menschen tolerieren kleine Verzögerungen erstaunlich gut, solange das System sich nachvollziehbar verhält: Die eigene Änderung ist sofort sichtbar, Zahlen springen nicht rückwärts, und bei wichtigen Vorgängen gibt es eine klare Bestätigung. Genau diese Eigenschaften lassen sich auch mit zeitverzögerten Kopien erreichen, wenn man sie bewusst plant. Ein System, das sich für Nutzer konsistent anfühlt, muss also nicht überall streng konsistent sein – es muss nur an den richtigen Stellen konsistent sein und an den anderen Stellen verständlich reagieren.

Halten Sie diese Entscheidungen für jedes wichtige Datum im Anforderungsdokument fest. Das schützt davor, dass bei späteren Optimierungen versehentlich eine kritische Abfrage auf ein Replikat oder einen Cache umgelenkt wird – ein Fehler, der oft erst unter Last und dann sehr unangenehm auffällt. Ein kurzer Kommentar im Code an den kritischen Stellen, etwa „muss vom Primärserver lesen“, wirkt dabei oft Wunder und schützt vor gut gemeinten, aber gefährlichen Optimierungen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.