Das CAP Theorem praktisch verstehen

1. Was das CAP Theorem tatsaechlich behauptet

Das CAP Theorem, formuliert von Eric Brewer und spaeter formal bewiesen von Gilbert und Lynch, besagt, dass ein verteiltes System nicht gleichzeitig Konsistenz, Verfuegbarkeit und Partitionstoleranz vollstaendig garantieren kann. Konsistenz bedeutet hier, dass jede Leseoperation den zuletzt geschriebenen Wert liefert, Verfuegbarkeit bedeutet, dass jede Anfrage eine Antwort erhaelt, und Partitionstoleranz bedeutet, dass das System trotz Nachrichtenverlust zwischen Knoten weiterhin funktioniert.

Eine haeufige Fehlinterpretation ist, das CAP Theorem als Auswahl von zwei aus drei Eigenschaften zu verstehen, als koenne man frei zwischen CA, CP und AP waehlen. In der Praxis ist Partitionstoleranz keine Option, sondern eine physikalische Notwendigkeit: Netzwerke fallen aus, Pakete gehen verloren, Latenzen schwanken unvorhersehbar. Ein verteiltes System, das mehr als einen Knoten besitzt, muss Partitionstoleranz akzeptieren, ob es will oder nicht. Die eigentliche Entscheidung, die das CAP Theorem erzwingt, liegt deshalb zwischen Konsistenz und Verfuegbarkeit, und zwar nur waehrend einer tatsaechlichen Partition, nicht im Normalbetrieb.

Diese Praezisierung ist entscheidend: ausserhalb einer Partition kann ein gut entworfenes System durchaus sowohl konsistent als auch verfuegbar sein. Das CAP Theorem trifft keine Aussage ueber den Normalbetrieb, sondern ausschliesslich ueber das Verhalten waehrend einer Netzwerkstoerung. Diese Einschraenkung wird in vielen vereinfachten Darstellungen des Theorems uebergangen, fuehrt aber in der Praxis zu grundlegend falschen Architekturentscheidungen, wenn sie ignoriert wird.

2. Netzwerkpartitionen sind der Normalfall, nicht die Ausnahme

Eine Netzwerkpartition entsteht, wenn Knoten eines verteilten Systems sich zwar noch fuer sich funktionsfaehig, aber nicht mehr gegenseitig erreichbar sind. In cloudbasierten Umgebungen mit mehreren Rechenzentren oder Verfuegbarkeitszonen sind solche Partitionen keine seltenen Katastrophenfaelle, sondern statistisch erwartbare Ereignisse: Netzwerkkomponenten haben Ausfallraten, Zwischenrouting kann fehlschlagen, und selbst kurzzeitige Latenzspitzen wirken sich wie eine temporaere Partition aus, wenn Timeout-Werte ueberschritten werden.

Ein System, das fuer den Idealfall entworfen wurde und Partitionen als Ausnahme behandelt, reagiert im Ernstfall oft unvorhersehbar: manche Knoten geben veraltete Daten aus, andere lehnen Anfragen komplett ab, ein drittes Verhalten tritt inkonsistent zwischen verschiedenen Anfragen desselben Nutzers auf. Die bewusste Entscheidung, wie sich ein System waehrend einer Partition verhalten soll, noch bevor sie tatsaechlich auftritt, ist der eigentliche praktische Nutzen des CAP Theorems fuer Architekturentscheidungen.

Diese Entscheidung ist kein einmaliges globales Attribut eines Systems, sondern kann und sollte pro Datentyp und pro Operation getroffen werden. Ein E-Commerce-System kann fuer Produktbeschreibungen Verfuegbarkeit priorisieren, waehrend es fuer Zahlungsvorgaenge Konsistenz priorisiert, innerhalb derselben Gesamtarchitektur. Diese Granularitaet wird in vereinfachten Diskussionen des CAP Theorems haeufig uebersehen.

3. CP-Systeme: Konsistenz vor Verfuegbarkeit

Ein CP-System (Consistency, Partition tolerance) entscheidet sich waehrend einer Partition dafuer, Anfragen abzulehnen oder zu verzoegern, statt potenziell veraltete Daten zurueckzugeben. Klassische relationale Datenbanken mit synchroner Replikation, sowie Systeme wie etcd oder ZooKeeper, die auf Konsensprotokollen wie Raft basieren, folgen diesem Muster: lieber keine Antwort als eine falsche Antwort.

Der praktische Vorteil liegt in der Vorhersagbarkeit: Anwendungscode, der auf ein CP-System aufbaut, kann sich darauf verlassen, dass jede erfolgreiche Antwort den aktuellsten Stand widerspiegelt, ohne zusaetzliche Logik fuer den Umgang mit veralteten Daten implementieren zu muessen. Diese Einfachheit auf Anwendungsseite wird durch reduzierte Verfuegbarkeit waehrend Netzwerkstoerungen erkauft, ein klarer Tradeoff, der fuer Konfigurationsdaten, Feature-Flags oder verteilte Sperren oft die richtige Wahl ist.

CP-Systeme eignen sich besonders fuer Daten, bei denen eine veraltete Antwort schaedlicher ist als gar keine Antwort. Ein verteilter Lock-Service, der bei einer Partition falsche Sperrinformationen liefert, kann zu gleichzeitigem Zugriff auf eine kritische Ressource fuehren, waehrend eine kurzzeitig nicht erreichbare Sperrenanfrage lediglich zu einer Verzoegerung fuehrt, meist die deutlich harmlosere Konsequenz.

-- Beispiel: CP-Verhalten durch synchrone Replikation erzwingen (PostgreSQL)
-- Commit wartet auf Bestaetigung der synchronen Replica
ALTER SYSTEM SET synchronous_standby_names = 'replica_1';
ALTER SYSTEM SET synchronous_commit = 'on';

-- Waehrend einer Partition: Schreibzugriffe blockieren,
-- statt inkonsistente Daten zu akzeptieren
BEGIN;
INSERT INTO critical_config (key, value) VALUES ('feature_x', 'enabled');
COMMIT;
-- Commit haengt, wenn synchrone Replica nicht erreichbar ist,
-- statt sofort mit unbestaetigter Aenderung zurueckzukehren

4. AP-Systeme: Verfuegbarkeit vor Konsistenz

Ein AP-System (Availability, Partition tolerance) beantwortet jede Anfrage, auch waehrend einer Partition, akzeptiert dafuer aber, dass verschiedene Knoten voruebergehend unterschiedliche Antworten liefern koennen. Datenbanken wie Cassandra oder DynamoDB im Standardkonfigurationsmodus folgen diesem Muster: Verfuegbarkeit hat Prioritaet, Konflikte werden nach der Partition ueber definierte Mechanismen wie Last-Write-Wins oder Vector Clocks aufgeloest.

Der praktische Vorteil ist Robustheit gegenueber Netzwerkstoerungen: eine Anwendung, die auf ein AP-System aufbaut, bleibt fuer Nutzer funktionsfaehig, auch wenn Teile der Infrastruktur voruebergehend nicht miteinander kommunizieren koennen. Dieser Vorteil verlagert aber Komplexitaet in die Anwendungsschicht: sie muss mit moeglicherweise widerspruechlichen Daten umgehen koennen, etwa durch Conflict-Resolution-Logik oder durch die bewusste Entscheidung, dass geringfuegige Inkonsistenzen fuer den jeweiligen Anwendungsfall akzeptabel sind.

AP-Systeme eignen sich gut fuer Daten, bei denen kurzzeitige Inkonsistenz tolerierbar ist und Verfuegbarkeit den hoeheren Geschaeftswert hat. Ein Warenkorb in einem Onlineshop, ein Like-Zaehler in sozialen Medien oder Session-Daten sind typische Beispiele: eine geringfuegig veraltete Anzeige ist meist unproblematisch, waehrend eine komplett nicht erreichbare Anwendung direkten Umsatzverlust bedeutet.

5. Haeufige Missverstaendnisse ueber CAP

Ein weit verbreitetes Missverstaendnis ist, CA-Systeme, also Konsistenz und Verfuegbarkeit ohne Partitionstoleranz, als praktikable dritte Option zu betrachten. Ein System ohne Partitionstoleranz funktioniert nur, solange keine Partition auftritt, was fuer jedes System mit mehr als einem Knoten in der Praxis unrealistisch ist. Eine klassische Single-Node-Datenbank ist technisch CA, aber eben auch kein verteiltes System im eigentlichen Sinn, fuer das CAP ueberhaupt relevant waere.

Ein zweites Missverstaendnis ist, CAP-Klassifizierungen als statische, systemweite Eigenschaft zu behandeln. MongoDB etwa kann je nach Konfiguration von Read- und Write-Concern sowohl staerker CP als auch staerker AP konfiguriert werden, innerhalb derselben Installation. Die Aussage "MongoDB ist ein CP-System" oder "Cassandra ist ein AP-System" ist eine grobe Vereinfachung, die die tatsaechliche Konfigurierbarkeit vieler moderner Systeme ignoriert.

Ein drittes Missverstaendnis betrifft den Zeitrahmen: CAP beschreibt das Verhalten waehrend einer Partition, nicht die generelle Konsistenzgarantie eines Systems. Ein System kann ausserhalb von Partitionen stark konsistent sein und gleichzeitig als AP klassifiziert werden, weil es sich waehrend einer Partition fuer Verfuegbarkeit entscheidet. Diese zeitliche Praezisierung wird in Diskussionen haeufig vernachlaessigt, fuehrt aber zu erheblichen Missverstaendnissen bei der Systemauswahl.

6. PACELC: die Erweiterung um Latenz

Daniel Abadi erweiterte das CAP Theorem um das PACELC-Modell, das eine wichtige Luecke schliesst: CAP beschreibt nur das Verhalten waehrend einer Partition (P), sagt aber nichts ueber den Normalbetrieb aus. PACELC ergaenzt: waehrend einer Partition (P) waehlt man zwischen Verfuegbarkeit (A) und Konsistenz (C), ansonsten (E, else) waehlt man zwischen Latenz (L) und Konsistenz (C).

Diese Erweiterung erklaert, warum selbst ausserhalb einer Partition viele Systeme bewusst auf eine gewisse Konsistenzgarantie verzichten: synchrone Replikation ueber mehrere geografisch verteilte Rechenzentren hinweg kostet messbare Latenz bei jedem Schreibvorgang, auch wenn keine Partition vorliegt. Ein System, das PACELC-konform als PA/EL klassifiziert wird, waehlt Verfuegbarkeit waehrend einer Partition und niedrige Latenz im Normalbetrieb, auf Kosten strikter Konsistenz in beiden Faellen.

PACELC macht damit sichtbar, dass die CAP-Entscheidung nur die Haelfte der relevanten Tradeoffs beschreibt. Ein Architekturteam, das nur CAP betrachtet, uebersieht die taeglich relevantere Frage: wie viel Latenz ist eine Anwendung bereit, fuer staerkere Konsistenzgarantien im Normalbetrieb zu bezahlen, eine Frage, die weit haeufiger auftritt als eine tatsaechliche Netzwerkpartition.

-- Beispiel: PACELC-Tradeoff sichtbar machen durch Read-Concern-Wahl
-- Starke Konsistenz, hoehere Latenz (waehrend UND ausserhalb einer Partition)
-- Read von Primary erzwingen statt von einer moeglicherweise veralteten Replica

-- Konfiguration eines Lesevorgangs mit expliziter Konsistenzanforderung
-- (Pseudo-Syntax, wie sie in vielen verteilten Datenbanktreibern vorkommt)

-- Stark konsistent, hoehere Latenz:
-- read_preference = 'primary'

-- Niedrige Latenz, moeglicherweise veraltete Daten:
-- read_preference = 'nearest_replica'

7. CAP-Entscheidungen in echten Systemen treffen

Die praktische Anwendung des CAP Theorems beginnt mit der Klassifizierung von Daten nach ihrer Konsistenzanforderung, nicht mit der Wahl einer Datenbanktechnologie. Finanzielle Transaktionen, Bestandsdaten vor einem Checkout und Berechtigungspruefungen gehoeren typischerweise zu Daten, bei denen CP-Verhalten gerechtfertigt ist, weil eine falsche Antwort schwerwiegendere Folgen hat als eine verzoegerte oder abgelehnte Anfrage.

Anzeige-Daten, Empfehlungen, Analytics und die meisten Lesevorgaenge in oeffentlichen Bereichen einer Anwendung vertragen dagegen AP-Verhalten gut: eine kurzzeitig veraltete Produktbeschreibung oder ein leicht verzoegerter Like-Zaehler haben selten spuerbare negative Konsequenzen, waehrend eine komplett nicht erreichbare Anwendung immer eine negative Konsequenz hat.

Ein praktikabler Ansatz ist es, diese Klassifizierung explizit im Architekturdokument festzuhalten, statt sie implizit der jeweiligen Datenbanktechnologie zu ueberlassen. Ein Team, das bewusst entscheidet, welche Daten CP- und welche AP-Verhalten brauchen, trifft bessere Entscheidungen bei der Technologieauswahl, als eines, das eine einzelne Datenbanktechnologie fuer alle Datentypen einsetzt und hofft, dass die Standardkonfiguration passt.

8. Feingranulare CAP-Entscheidungen pro Operation

Moderne verteilte Datenbanken erlauben es zunehmend, die CAP-Entscheidung pro einzelner Operation statt systemweit zu treffen. Cassandra beispielsweise erlaubt es, den Konsistenzlevel pro Lese- oder Schreibanfrage individuell festzulegen, von ONE (schnell, wenig konsistent) bis QUORUM oder ALL (langsamer, staerker konsistent). Dieselbe Datenbankinstanz kann so fuer unterschiedliche Anfragetypen unterschiedliche Punkte im CAP-Spektrum bedienen.

Diese Feingranularitaet erlaubt es, innerhalb einer einzigen Anwendung fuer kritische Schreibzugriffe QUORUM-Konsistenz zu verlangen, waehrend unkritische Lesezugriffe mit ONE-Konsistenz und entsprechend niedrigerer Latenz auskommen. Der Preis fuer diese Flexibilitaet ist zusaetzliche Komplexitaet im Anwendungscode, der explizit fuer jede Operation die passende Konsistenzanforderung waehlen muss, statt sich auf eine einzige, systemweite Voreinstellung zu verlassen.

Ein haeufiger Fehler ist es, den Konsistenzlevel einmalig beim initialen Aufbau der Anwendung festzulegen und danach nie wieder zu ueberdenken, obwohl sich die Konsistenzanforderungen einzelner Datentypen im Laufe der Produktentwicklung veraendern. Regelmaessige Ueberpruefung, welche Operationen tatsaechlich welche Konsistenzgarantie brauchen, verhindert, dass veraltete Annahmen unnoetig hohe Latenz oder unnoetig hohes Inkonsistenzrisiko erzeugen.

9. CAP-Einordnung gaengiger Datenbanksysteme

Die folgende Tabelle ordnet gaengige Datenbanksysteme grob entlang des CAP-Spektrums ein, mit dem Hinweis, dass viele Systeme konfigurierbar sind und diese Einordnung eine Vereinfachung darstellt.

Diese Tabelle zeigt vor allem eines: die Wahl eines Datenbanksystems allein legt noch keine CAP-Strategie fest. Die tatsaechliche Konfiguration, oft unterschiedlich pro Datentyp innerhalb derselben Anwendung, entscheidet, wo ein System im CAP-Spektrum tatsaechlich operiert, nicht die grundsaetzliche Produktkategorie.

10. Zusammenfassung

Das CAP Theorem praktisch zu verstehen bedeutet, es nicht als Auswahl von zwei aus drei Eigenschaften misszuverstehen, sondern als erzwungene Entscheidung zwischen Konsistenz und Verfuegbarkeit, ausschliesslich waehrend einer Netzwerkpartition. Partitionstoleranz ist keine Option, sondern eine physikalische Notwendigkeit fuer jedes System mit mehr als einem Knoten. CP-Systeme priorisieren korrekte Antworten, AP-Systeme priorisieren Erreichbarkeit, beide mit klaren, unterschiedlichen Anwendungsfaellen.

PACELC erweitert diese Betrachtung sinnvoll um den Normalbetrieb: die Frage nach Latenz gegenueber Konsistenz tritt weit haeufiger auf als eine tatsaechliche Partition und verdient mindestens so viel architektonische Aufmerksamkeit. Die praktisch wichtigste Erkenntnis ist, CAP-Entscheidungen pro Datentyp zu treffen, statt eine einzige Strategie fuer die gesamte Anwendung zu erzwingen, weil unterschiedliche Daten fundamental unterschiedliche Konsistenzanforderungen haben.

11. FAQ: Das CAP Theorem praktisch verstehen