In der idealen Welt der Daten sind diese immer verfügbar, stets konsistent und können beliebig verteilt werden.

Leider stellte der Informatiker Eric Brewer im Jahr 2000 die These auf, das dies bei verteilten Systemen nicht möglich ist. 2002 wurde diese These durch einen axiomatischen Beweis bestätigt und damit zum Theorem.

Das CAP Theorem besagt:

Bei verteilten Datensystemen kannst Du nur zwei der drei Eigenschaften Konsistenz, Verfügbarkeit und Partitionstoleranz erfüllen.

Um das daraus für die Software Architektur entstehende Dilemma zu verdeutlichen, möchte ich 3 Beispiele aufführen.

Fehlende Partitionstoleranz

Gute Beispiele für den Verzicht auf Partitionstoleranz sind SQL-Datenbanken im klassischen Einsatz, geclusterte Datenbanken oder ein LDAP. Hier können Änderungen transaktionssicher vorgenommen werden. Auch kann die Verfügbarkeit z.B. durch ein Master-Slave System sicher gestellt werden. Aber diese Systeme können nicht beliebig und unabhängig voneinander verteilt werden.

Fehlende Verfügbarkeit

Dies ist bei allen Destributed DB’s und vielen verteilten Filesystemen der Fall. Merkregel: Immer wenn Lock-Mechanismen im Einsatz sind, ist Verfügbarkeit nicht vollständig gewährleistet.

Fehlende Konsistenz

Fehlende Konsistenz ist in hochskalierten Webanwendnungen die Regel. Ein gutes Beispiel sind das DNS, aber auch die Google Suche. Jeder, der schon mal bei einem Livegang den C-Name geändert hat kennt das Problem: Ein Teil der User sieht noch die alte Webseite, während andere schon auf der Neuen surfen.

Auswahl im realen Einsatz

Um das CAP-Dilemma zu lösen, nutzen reale Internetseiten häufig einen von den Anforderungen abhängigen Mix. Beispiel: Amazon wird für die Präsentation seiner Waren und das Ausspielen von Widgets großen Wert auf Verfügbarkeit und Partitionstoleranz legen und dabei gerne auf einen Teil der Konsistenz verzichten. Wenn der Amazonkunde dann in den Bestellvorgang wechselt, wird die Konsistenz dagegen unverzichtbar sein.
Die Auswahl ist nicht allein von der technischen Wahl abhängig, sondern oft von der erstellten Architektur. Beispiel: MySQL-Datenbanken können bei Verwendung von InnoDB transaktionssicher eingesetzt werden und absolute Konsistenz gewährleisten. Man kann sie aber auch partitioniert aufsetzen und unter Verzicht auf die Konsistenz hochverfügbar Inhalte bereitstellen.