CAP-Theorem

Das CAP-Theorem ist eines der zentralen Resultate der verteilten Systeme. Es wurde 2000 von Eric Brewer aufgestellt und 2002 mathematisch bewiesen. Die Aussage in einem Satz: ein verteiltes System kann von den drei Eigenschaften Consistency, Availability und Partition Tolerance nur zwei gleichzeitig vollständig garantieren – die dritte muss opfern. Klingt abstrakt, hat aber massive Konsequenzen dafür, welche Datenbank du wann wählst.

In der NoSQL-Welt ist das CAP-Theorem zentral, weil viele NoSQL-Systeme von Grund auf verteilt sind. SQL-Datenbanken laufen klassisch auf einer Maschine und müssen sich nicht damit auseinandersetzen. Sobald du aber Daten auf mehrere Server verteilst (z.B. horizontale Skalierung aus Lektion 1), bekommst du CAP als Limit – ob du willst oder nicht.

1) Die drei Buchstaben

Das C in CAP ist nicht dasselbe wie das C in ACID – das ist eine Falle, die viele Lernende stolpern lässt. Hier die korrekten Definitionen:

• C – Consistency (Konsistenz): alle Knoten im System haben zu jedem Zeitpunkt dieselbe Sicht auf die Daten. Eine Schreiboperation gilt erst als erfolgreich, wenn alle Knoten sie übernommen haben. Liest man danach auf irgendeinem Knoten, bekommt man garantiert den neuesten Wert.
• A – Availability (Verfügbarkeit): jeder Knoten antwortet immer auf Anfragen, auch wenn er gerade keinen Kontakt zu anderen Knoten hat. „Niemals einen Fehler zurückgeben" ist die Anforderung.
• P – Partition Tolerance (Partitionstoleranz): das System funktioniert weiter, auch wenn die Netzwerkverbindung zwischen Knoten zeitweise ausfällt und das Netzwerk in zwei oder mehr „Partitionen" zerfällt.

In einem nicht-verteilten System sind alle drei einfach. Das Problem entsteht erst, sobald mehrere Knoten beteiligt sind und das Netzwerk dazwischen unzuverlässig wird – was es in der echten Welt immer ist.

2) Das CAP-Dreieck

Die klassische Visualisierung: ein Dreieck mit C, A und P an den Ecken. Jede DB sucht sich zwei der drei Eigenschaften aus, die sie garantiert. Klick die Kanten um die drei Kombinationen zu erkunden:

3) Was passiert konkret bei einer Netzwerk-Partition?

Stell dir vor du hast zwei Datenbank-Knoten – einer in Frankfurt, einer in München. Sie replizieren ständig die Daten. Plötzlich fällt die Leitung zwischen beiden aus: Frankfurt kann München nicht erreichen, umgekehrt auch nicht. Jeder Knoten weiß: „Da gibt's einen Partner, aber ich höre nichts mehr". Was tun?

4) Wo bekannte Datenbanken einsortiert werden

In der Praxis werden Datenbanken nach diesem Schema klassifiziert. Achtung: die Einordnung ist oft eine Vereinfachung – viele moderne DBs sind konfigurierbar und können je nach Einstellung in unterschiedliche Quadranten fallen.

5) BASE als Gegenstück zu ACID

Für AP-Systeme hat sich ein eigenes Akronym etabliert, als Gegenstück zu ACID: BASE.

• Basically Available – das System ist meist erreichbar, auch bei Teilausfällen.
• Soft state – der Zustand kann sich auch ohne neuen Input ändern (z.B. durch Hintergrund-Replikation).
• Eventually consistent – wenn lang genug keine neuen Schreibvorgänge passieren, gleichen sich alle Knoten an und liefern dieselben Werte.

BASE ist schwächer als ACID, das ist der Punkt. Es heißt nicht „falsch" – es heißt „andere Garantien für andere Use Cases". Für Likes auf Instagram darf der Counter zwei Sekunden alt sein, das merkt niemand. Für Banküberweisungen ist das undenkbar. BASE für das eine, ACID für das andere.

6) PACELC – das erweiterte Theorem

CAP hat eine Schwäche: es spricht nur über das Verhalten während einer Partition. Was ist im Normalfall, wenn das Netzwerk fein ist? Das erweitert das PACELC-Theorem (sprich: „pass-elk"):

Wenn eine Partition (P) auftritt, muss zwischen Availability (A) und Consistency (C) gewählt werden. Else (E), im Normalbetrieb, muss zwischen Latency (L) und Consistency (C) gewählt werden.

Heißt: auch ohne Netzwerkproblem gibt es einen Trade-off. Wer starke Konsistenz will, muss bei jedem Schreibvorgang warten bis alle Knoten bestätigen – das kostet Zeit (Latency). Wer schnelle Antworten will, akzeptiert evtl. kurz veraltete Werte. PACELC wird in der Forschung als realistischer angesehen, in IHK-Prüfungen kommt es selten vor – CAP reicht meist.

7) CAP-Theorem in IHK-Aufgaben

In der Prüfung wird CAP gern als kurze Wissensabfrage oder Szenario-Analyse gestellt. Drei typische Aufgabentypen, die du beantworten können solltest:

• Begriffe nennen: „Wofür stehen die drei Buchstaben in CAP?" – Consistency, Availability, Partition Tolerance.
• Trade-off erklären: „Warum kann ein verteiltes System nicht alle drei garantieren?" – Antwort: bei einer Partition muss man wählen, ob man Schreibvorgänge ablehnt (CP) oder beide Seiten unabhängig weiterlaufen lässt (AP).
• Use Case einordnen: „Welche Eigenschaft ist für einen Online-Shop / eine Banküberweisung / ein Social Network wichtiger?" – Bank: CP. Social Network: meist AP. Shop: variiert, oft AP für Katalog, CP für Bezahlung.

Ein klassischer Fehler ist, „Konsistenz" in CAP mit „Konsistenz" in ACID gleichzusetzen. Sie sind nicht dasselbe – ACID-Konsistenz meint „Constraints sind nach der Transaktion eingehalten", CAP-Konsistenz meint „alle Knoten sehen denselben Stand". Wer das in der Antwort sauber trennt, bekommt Bonus-Punkte.

Zusammenfassung

Das CAP-Theorem (Brewer, 2000) besagt: ein verteiltes System kann von Consistency (alle Knoten sehen denselben Stand), Availability (jeder Knoten antwortet immer) und Partition Tolerance (System bleibt funktionsfähig bei Netzwerk-Ausfall) nur zwei gleichzeitig vollständig garantieren. In der Praxis ist P ein Muss in jedem verteilten System – die echte Wahl ist CP (lieber Konsistenz, dafür kann ein Knoten ausfallen) oder AP (lieber Verfügbarkeit, dafür kurze Inkonsistenz). CA-Systeme sind faktisch nicht-verteilt (typische single-node SQL-DB). Bekannte Einordnung: MongoDB, HBase, Spanner = CP. Cassandra, DynamoDB, CouchDB = AP. Verwandt: BASE (Basically Available, Soft state, Eventually consistent) als Gegenstück zu ACID. Wichtig: das C in CAP ist nicht dasselbe wie das C in ACID – CAP-C meint Replikate-Konsistenz, ACID-C meint Regelkonformität. Erweiterung: PACELC berücksichtigt auch den Normalbetrieb (Latency vs. Consistency).