Das CAP-Theorem, ehrlich erklärt: Was es wirklich für die Datenbankwahl bedeutet

Jeder Datenbankvergleich landet irgendwann beim selben Dreieck. Consistency, Availability, Partition tolerance — wähle zwei. Es sieht sauber aus, passt auf eine Folie und ist genau auf die Art falsch, die dich still einen Ausfall kostet.

Das CAP-Theorem ist real und es ist nützlich. Aber die „Zwei-von-drei“-Fassung hat eine ganze Generation von System-Design-Interviews in die Irre geführt. Partitionen sind keine Eigenschaft, die du dir aussuchst. Sie sind das, was das Netzwerk an einem Dienstagnachmittag mit dir macht. Wer das begriffen hat, für den ist CAP kein Party-Trick mehr, sondern ein echtes Werkzeug für die Frage, wo die Daten leben.

Das ist die ehrliche Version: was die drei Buchstaben wirklich bedeuten, die eine Entscheidung, zu der CAP zwingt, und wie du sie in eine begründbare Datenbankwahl übersetzt.

Drei Wörter, die nicht das bedeuten, was du denkst

Vor dem Trade-off die Definitionen — denn die meisten CAP-Streits sind in Wahrheit Vokabelstreits.

• Konsistenz heißt hier Linearisierbarkeit: Jeder Lesezugriff liefert den letzten Schreibzugriff, als gäbe es nur eine einzige Kopie der Daten. Das ist nicht das „C“ aus ACID. Gleicher Buchstabe, anderes Universum.
• Verfügbarkeit bedeutet, dass jede Anfrage an einen nicht-ausgefallenen Knoten eine (fehlerfreie) Antwort bekommt. Nicht „schnell“, nicht „meistens erreichbar“ — eine echte Antwort, jedes Mal.
• Partitionstoleranz bedeutet, dass das System weiterarbeitet, selbst wenn das Netzwerk Nachrichten zwischen Knoten verwirft oder verzögert.

Lies das noch einmal, und der Mythos zerfällt von selbst. Eine verteilte Datenbank läuft über ein Netzwerk. Netzwerke partitionieren — ein Switch stirbt, ein Kabel wird gekappt, eine Cloud-AZ geht dunkel. Du kannst das nicht nicht tolerieren. P steht nicht zur Wahl.

Die einzige Wahl, zu der CAP wirklich zwingt

Wenn Partitionstoleranz also Pflicht ist — worum geht es im Theorem dann wirklich? Um einen einzigen, scharfen Moment.

Wenn eine Partition deinen Cluster in zwei Gruppen spaltet, die nicht mehr miteinander reden können, steht jede Seite vor einer Frage zu einem Datum, das sie nicht vollständig verifizieren kann:

• Konsistent bleiben (CP): nicht antworten, solange nicht sicher ist, dass der letzte Stand vorliegt. Die Minderheitsseite lehnt Schreibzugriffe ab, vielleicht auch Lesezugriffe, und wartet, bis das Netz heilt. Korrekt, aber vorübergehend nicht verfügbar.
• Verfügbar bleiben (AP): trotzdem antworten, mit dem, was dieses Replikat weiß, und die Divergenz später abgleichen. Immer ansprechbar, aber möglicherweise mit veralteten Daten.

Das ist das ganze Theorem. Nicht „zwei von drei“ — C oder A, und nur, solange eine Partition dauert. Ist das Netz gesund, hast du beides. CAP beschreibt das Verhalten eines Systems unter einem Fehler, nicht seine dauerhafte Persönlichkeit.

Eine Bank, die Geld bewegt, wählt CP: ein Double-Spend ist schlimmer als eine Fehlermeldung. Ein Social-Feed wählt AP: ein leicht veralteter Like-Zähler ist unsichtbar, ein Spinner nicht.

Der Teil, den CAP auslässt: die anderen 99 % der Zeit

Hier ist die Falle, die „zwei von drei“ komplett verdeckt. Partitionen sind selten. Ein gut betriebener Cluster verbringt den überwältigenden Teil seines Lebens voll verbunden. CAP sagt über diese Zeit nichts — und in dieser Zeit lebst du tatsächlich.

Deshalb ist PACELC so wichtig. Es erweitert CAP um den Normalfall:

Gibt es eine Partition, wähle Availability oder Consistency — Else (L), wenn alles gesund ist, wähle Latenz oder Consistency.

Diese zweite Klausel ist die Entscheidung, die du bei jeder Anfrage triffst. Starke Konsistenz ist nicht gratis, selbst wenn das Netz perfekt ist: Zu bestätigen, dass ein Lesezugriff den letzten Schreibzugriff widerspiegelt, heißt über Replikate hinweg zu koordinieren, und Koordination kostet Millisekunden. Lockere die Konsistenz, und Lesezugriffe werden schneller; ziehe sie an, und sie werden langsamer, aber wahrer.

Der echte, tägliche Trade-off ist also nicht das dramatische Ausfallszenario. Er lautet: Wie viel Latenz zahlst du auf dem Happy Path, um sicher zu sein, dass deine Daten aktuell sind? Diese Frage feuert millionenfach am Tag. Die Partitionsfrage feuert einmal im Quartal.

Es ist pro Operation, nicht pro Datenbank

Das andere, was das Dreieck falsch macht: Konsistenz und Verfügbarkeit sind keine festen Eigenschaften, die einer Datenbank aufgeprägt sind. Es sind Entscheidungen, die du pro Operation triffst.

Die meisten modernen verteilten Stores machen das direkt über Quoren zugänglich. Bei N Replikaten wartet ein Lesezugriff auf R Antworten und ein Schreibzugriff auf W Bestätigungen. Setze R + W > N, und jeder Lesezugriff sieht garantiert den letzten bestätigten Schreibzugriff — starke Konsistenz, höhere Latenz. Setze sie niedriger, und du tauschst Aktualität gegen Tempo.

-- Cassandra: den Trade-off pro Statement wählen.
-- Stark: Lese- und Schreibquoren überlappen (R + W > N).
CONSISTENCY QUORUM;
INSERT INTO ledger (acct, delta) VALUES ('A42', -100);

-- Schnell und verfügbar: vom nächsten Replikat antworten, Veraltung akzeptieren.
CONSISTENCY ONE;
SELECT likes FROM post WHERE id = 'p_9f3';

Derselbe Cluster ist CP für den Ledger-Schreibzugriff und AP für den Like-Zähler. Du wählst nicht die Philosophie einer Datenbank; du wählst die Garantie, die diese konkrete Anfrage braucht. DynamoDB hat sein ConsistentRead-Flag, Cosmos DB liefert fünf Konsistenzstufen, MongoDB kennt Read/Write Concerns. Das Label auf der Verpackung ist ein Default, kein Schicksal.

Wo landen die Datenbanken also wirklich?

Defaults zählen trotzdem, denn sie sind das, was du bekommst, bevor du irgendetwas justierst. Grob:

• Tendenz CP — Google Spanner, HBase, etcd, ZooKeeper, MongoDB (Default Majority). Sie lehnen während einer Partition ab oder blockieren, um Korrektheit zu schützen. Spanner ist der interessante Fall: CP by Design, steckt aber enorme Ingenieursarbeit — TrueTime, redundante private Vernetzung — hinein, um Partitionen so selten zu machen, dass es sich hochverfügbar anfühlt.
• Tendenz AP — Cassandra, DynamoDB, Riak, CouchDB. Sie antworten während eines Splits weiter und gleichen danach ab, mit Mechanismen wie Last-Write-Wins oder CRDTs.

Und der Mythos, der begraben gehört: Es gibt keine sinnvolle „CA“-Datenbank. „CA“ beschreibt nur einen einzelnen Knoten ohne Netzwerk, das partitionieren könnte — eine einsame Postgres-Instanz. In dem Moment, in dem du sie replizierst oder shardest, steht Postgres vor genau derselben CP-gegen-AP-Wahl wie alles andere. Wenn ein Design-Dokument etwas „CA“ nennt, liest da jemand das Dreieck, nicht das System.

Wie man tatsächlich wählt

Lass das Dreieck weg. Stell drei Fragen, in dieser Reihenfolge.

1. Welche Invariante darf niemals brechen? Wenn zwei Nutzer denselben Kontostand ausgeben können oder zwei Bestellungen die letzte Einheit im Lager beanspruchen, brauchst du auf diesem Pfad CP. Korrektheit zuerst; eine abgelehnte Anfrage ist wiederholbar, eine korrumpierte Invariante oft nicht.
2. Was verträgt es, leicht veraltet zu sein? Warenkörbe, Feeds, Aufrufzähler, Empfehlungen, Sessions, Telemetrie — ein paar Sekunden Rückstand sind für Nutzer unsichtbar und die Verfügbarkeit und das Tempo wert. Das ist AP, und das ist der Großteil deines Traffics.
3. Welche Latenz verträgt der Happy Path? Das ist die PACELC-Frage. Wenn ein Lesezugriff stark konsistent und p99 unter 10 ms sein muss, verlangst du Koordination unter Zeitdruck — plane sie ein oder lockere eine der beiden Anforderungen.

Dann entwirf die Partition explizit, statt zu hoffen, dass sie nie kommt. Mach Schreibzugriffe idempotent, damit ein Retry nach dem Heilen sicher ist. Nutze Fencing-Tokens, damit ein veralteter Leader nicht handeln kann. Setze Geld und Identität hinter Quorum-Lesezugriffe; lass den Feed vom nächsten Replikat bedienen. Derselbe Cluster, unterschiedliche Garantien, mit Absicht gewählt.

Die Wahl des Stores ist die eine Entscheidung; den Traffic dorthin gesund zu halten die andere. Zur Messaging-Seite eines resilienten Systems siehe Pub/Sub oder Eventarc? Event-Driven auf GCP ohne Spaghetti und Eine Million Benachrichtigungen versenden, ohne abzustürzen.

Die Regel fürs Feld

Das CAP-Theorem ist kein Dreieck, aus dem du zwei Ecken aussuchst. Partitionen sind garantiert, also ist Partitionstoleranz fix. Die echte Wahl ist ein Moment — blockierst du während eines Splits, um korrekt zu bleiben (CP), oder antwortest du, um verfügbar zu bleiben (AP)? — und PACELC deckt die anderen 99 % der Zeit ab, in denen du bei jeder Anfrage Latenz gegen Konsistenz tauschst. Entscheide es pro Operation, nicht pro Datenbank: schütze die Invarianten, die nicht brechen dürfen, lockere alles, was ein bisschen Veraltung verträgt, und entwirf die Partition mit Absicht. Tu das, und „welche Datenbank“ hört auf, ein Glaubenskrieg zu sein, und wird das, was es sein sollte — ein Trade-off, den du mit offenen Augen getroffen hast.