In der Welt der verteilten Datenbanksysteme hat sich über die Jahre eine einfache, aber weit verbreitete Einteilung etabliert: Systeme werden als CP (konsistent und partitionstolerant) oder AP (verfügbar und partitionstolerant) kategorisiert – eine Interpretation der CAP-Theorie. Doch diese Bezeichnungen greifen heute in vielerlei Hinsicht zu kurz und führen oftmals zu Missverständnissen, die die Komplexität verteilter Systeme nicht ausreichend widerspiegeln. Es wird Zeit, diese Einteilung zu überdenken und durch präzisere Konzepte zu ersetzen, die den realen Anforderungen moderner Systeme besser entsprechen. Die CAP-Theorie, formuliert von Eric Brewer im Jahr 2000, ist eine wichtige theoretische Grundlage, die auf den ersten Blick leicht verständlich erscheint: Es sei unmöglich, gleichzeitig Konsistenz, Verfügbarkeit und Partitionstoleranz uneingeschränkt in einem verteilten System zu garantieren.
Daraus entstand die verbreitete Praxis, Systeme grundsätzlich in CP- oder AP-Kategorien zu stecken. Doch eine genauere Betrachtung offenbart erhebliche Einschränkungen und Missverständnisse in der Praxis. Eines der Hauptprobleme liegt in den strengen und besonderen Definitionen, die im Kontext der CAP-Theorie verwendet werden. Das Wort „Konsistenz“ in CAP bedeutet linearizability, eine äußerst starke Form der Konsistenz, welche sicherstellt, dass Operationen auf einer verteilten Datenbank so erscheinen, als würden sie in streng sequenzieller Ordnung stattfinden. Das unterscheidet sich deutlich von der „Konsistenz“ in ACID, wie sie oft in relationalen Datenbanken verstanden wird. Leider führen diese unterschiedlichen Begriffe in der Diskussion häufig zu Verwirrung. Ähnliches gilt für „Verfügbarkeit“. Im CAP-Kontext ist ein System verfügbar, wenn jede Anfrage, die an einen nicht ausgefallenen Knoten gerichtet wird, eine Antwort erhält, ohne Fehler oder Zeitüberschreitungen.
Das ist eine harte Definition, die viele Systeme, selbst solche, die allgemein als hochverfügbar gelten, eigentlich nicht erfüllen. In Wirklichkeit wird Verfügbarkeit oft differenzierter betrachtet, etwa über Service-Level-Agreements mit definierten Antwortzeiten. Selbst „Partitionstoleranz“ wird oft falsch verstanden. Partitionen sind Netzwerkunterbrechungen, bei denen Nachrichten verzögert oder verloren gehen können. Weil die meisten realen Netzwerke diese Eigenschaft besitzen, ist es mehr ein Grundvoraussetzung als eine Wahlmöglichkeit, sodass Partitionstoleranz in vielen Fällen nicht als eigenständige Alternative betrachtet werden sollte, sondern als notwendiges Fundament. Darüber hinaus ist der Geltungsbereich der CAP-Theorie äußerst eingeschränkt. Sie bezieht sich auf ein sehr einfaches Systemmodell – einen einzelnen, lesbar-schreibbaren Speicherregister.
Komplexere Systemaspekte wie Transaktionen über mehrere Objekte, unterschiedliche Fehlerarten jenseits von Netzwerkpartitionen oder Latenzzeiten werden komplett ausgeklammert. Gerade letzteres wird von Anwendern jedoch als essenziell empfunden, da extreme Antwortverzögerungen in der Praxis oft als Ausfall gelten. Ein weiteres Problem der CP-/AP-Einteilung ist, dass in Wirklichkeit viele Systeme weder so eindeutig kategorisierbar sind noch stets dieselben Eigenschaften für alle Operationen bereitstellen. Systeme mit Single-Leader-Replikation beispielsweise sind bei einer Trennung vom Leader nicht verfügbar für Schreiboperationen. Das widerspricht der Definition der Verfügbarkeit in CAP. Gleichzeitig erlauben sie durch asynchrone Replikation aber eventuell nicht-linearisierbare Leseoperationen, was wiederum der Konsistenzdefinition widerspricht. Solche Systeme sind damit weder CP noch AP im engeren Sinne und trotzdem häufig im Einsatz.
Auch moderne verteilte NoSQL-Datenbanken wie MongoDB oder Dynamo-ähnliche Systeme sind schwer zu klassifizieren. Ihre Konsistenz- und Verfügbarkeitsgarantien hängen stark von den jeweiligen Konfigurationen ab. Quorum-Abfragen etwa klingen auf den ersten Blick konsistent, aber in Kombination mit Mechanismen wie „sloppy quorums“ oder „read repair“ entstehen komplexe Situationen, in denen die starren CAP-Definitionen nicht mehr passend sind. Einfache Labels reichen hier nicht aus, um die tatsächlichen Betriebsmodi zu beschreiben. ZooKeeper, ein System, das oft als klassisches „CP“-System angesehen wird, illustriert dieses Problem besonders gut. Seine Standardleseoperationen sind nicht linearizable, was technisch gesehen nicht CAP-konsistent ist. Gleichzeitig besitzt es einen Schreibmechanismus, der im Falle von Partitionen einen Quorum-Mechanismus zur Verfügung stellt, der die Verfügbarkeit einschränkt.
Dennoch bietet ZooKeeper durch seine umfassenderen Konsistenzgarantien – wie atomaren Broadcast und Kausalitätsgarantien – ein sehr gutes Konsistenzniveau, das in der CAP-Betrachtung nicht erfasst wird. Diese Beispiele zeigen, dass die strikte Einteilung in CP oder AP-Systeme eine falsche Dichotomie ist, die vor allem dazu führt, dass wichtige Abstufungen und Realitäten moderner verteilten Systeme verloren gehen. Stattdessen sollte man differenziertere Begriffe und Modelle verwenden, die sich nach den tatsächlichen Konsistenz- und Verfügbarkeitsanforderungen einer Anwendung richten. Neue Frameworks und Konzepte bieten hier fortschrittliche Alternativen, um die Komplexität wirklich abzubilden. So beschreibt das PACELC-Modell beispielsweise nicht nur den Trade-off im Falle einer Partition, sondern auch im Normalbetrieb zwischen Latenz und Konsistenz.
Andere Arbeiten setzen auf eine feinere Klassifikation von Konsistenzmodellen, von Eventual Consistency über Kausalität bis hin zu Serialisierbarkeit und Linearizability. Darüber hinaus helfen erweiterte Isolationsebenen in Transaktionssystemen und umfassende Bewertungsmethoden, die Latenz, Fehlertoleranz, Programmiermodell und Operationen mit einzubeziehen. Diese bieten Entwicklern ein viel nuancierteres Bild und Hilfestellung bei der Wahl der richtigen Architektur und Technologie für ihre Anwendungsfälle. Wer sich mit verteilten Systemen beschäftigt, sollte daher lernen, über die Grenzen der CAP-Theorie hinauszudenken, die dort verwendeten Begriffe mit Vorsicht genießen und die verschiedenen Formen von Konsistenz, Verfügbarkeit und Partitionstoleranz durch konkrete Anforderungen ersetzen. Dies führt nicht nur zu besseren technischen Entscheidungen, sondern auch zu realistischeren Erwartungen gegenüber den eingesetzten Systemen.
Insgesamt hat die CAP-Theorie ohne Frage dazu beigetragen, das Bewusstsein für fundamentale Herausforderungen in verteilten Systemen weltweit zu schärfen. So startete sie eine lebhafte Diskussion über unvermeidbare Trade-offs und setzte wichtige Impulse für Forschung und Entwicklung. Heute aber haben wir einen viel größeren Werkzeugkasten an Modellen, Algorithmen und Architekturprinzipien zur Hand. Der Aufruf, Datenbanken nicht mehr pauschal als CP- oder AP-Systeme zu bezeichnen, ist deshalb ein Appell für mehr Genauigkeit, mehr Verständnis und differenziertere Kommunikation in der technischen Community. Weg von vereinfachten Labels, hin zu einem reflektierten und sachgemäßen Umgang mit den Eigenschaften verteilter Datenhaltung. Für Entwickler, Architekten und Ingenieure bedeutet das, dass sie ihre eigenen Anforderungen genau definieren müssen und dabei auf umfassendere Modelle zurückgreifen sollten.
Die Komplexität der heutigen Systeme verdient es, nicht auf zweidimensionale Kategorien reduziert zu werden. Nur so können Systeme mit den richtigen Kompromissen gebaut werden, die den individuellen Bedürfnissen von Anwendungen und Nutzern optimal entsprechen.
