CAP steht für Consistency, Availability, Partition tolerance, also Konsistenz, Verfügbarkeit und Partitionstoleranz. Es begann mit einer Vermutung von Eric Brewer im Jahre 2000. Zu einem Theorem wurde es erst 2002 durch den Beweis der Vermutung durch Gilbert und Lynch. Das Theorem besagt, dass man nicht alle drei gleichzeitig haben kann, also C, A und P.
Das hat Konsequenzen für moderne Anwendungen, die immer stärker ins Web gehen. Bei hoch-skalierbaren Webanwendungen müssen wir uns entscheiden zwischen Daten-Konsistenz und hoher Verfügbarkeit. Beides ist nicht in gleichem Maße zu maximieren. Also machen wir entweder eine transaktionsorientierte Konten-Verwaltung, bei der der Kunde auch schon mal ab und zu warten muss, bis er dran ist, oder eine Web 2.0-Anwendung, in der immer alle gleichzeitig bedient werden, allerdings ohne die Garantie, dass alle das Gleiche auf dem letzten Stand, d.h. das aktuell Richtige sehen.
Noch abstrakter gesprochen, müssen wir uns entscheiden zwischen Sicherheit und Lebendigkeit. Wollen wir die Sicherheit einer Konten-Verwaltung einer Bank oder die Lebendigkeit einer Web 2.0-Anwendung?
Amazon sagt, ein Zehntel Sekunde zusätzliche Verzögerung auf ihrer Webseite koste sie 1% Umsatz. Google hat festgestellt, eine zusätzliche halbe Sekunde Wartezeit koste sie ein Fünftel der Kundschaft.
Pure Wirtschaftlichkeitsargumente führen daher zu einer Bevorzugung der Lebendigkeit einer Web 2.0-Anwendung. Ausreichende Sicherheit bekomme man dann auch noch durch kluges Design (Ajax, Interaktionsstruktur, Navigationsstruktur, …) hin, so Julian Browne.