In dem InfoQ-Video erklärt Amazon CTO Werner Vogels, dass
in hoch skalierbaren Systemen jede Art von Abstimmungsprotokollen irgendwann zu einem Flaschenhals werden: (15:50) „Any agreement protocol will become your bottleneck.“ 2PC ist z.B. eine solches Abstimmungsprotokoll und hat bereits den Spitznamen Nichterreichbarkeitsprotokoll („Unavailability protocol“). Irgendwann in der Skalierung, schon bei kleinen Shops, wird es die Ursache für die schlechte Erreichbarkeit sein. Die Lösung liegt nicht darin, mehr Hardware zu kaufen, sondern die Gesamtaufgabe zu analysieren: Wo benötige ich wirklich Transaktionen? Wo kommt es wirklich auf Sicherheit an? Wo kann ich auf Transaktionen verzichten? Ist ein anderes Design der Serviceleistung denkbar und machbar, das genauso attraktiv, aber nicht so schwerfällig ist?
Das CAP-Theorem wird dann im Video bei (36:45) erklärt: Von den 3 Werten C, A und P kann man immer nur 2 haben. Ab (46:17) wird erklärt, bei welchen Systemen welche 2-er Kombis von C, A und P bei welchen Aufgabenstellungen gewählt werden. Requirements Engineering, welches das CAP-Theorem nicht beachtet, muss spätestens bei der Skalierung der Systeme scheitern. Das geschieht häufig erst sehr spät im Projektverlauf. Nun haben wir eine gute Erklärung, warum so viele große Systeme erst in späten Projektphasen gescheitert sind.
D.h. man gibt in skalierbaren, hoch-verfügbaren Systemen die Garantie der absoluten Korrektheit auf. Was wir also sehen, kann schon veraltet sein oder aus anderen Gründen nicht mehr stimmen. Das sollte natürlich nur an den Stellen passieren, an denen man sich das leisten kann.