Erklär das CAP-Theorem und wie es auf ein System zutraf, an dem du gearbeitet hast.

CAP sagt, dass du dich zwischen Konsistenz und Verfügbarkeit entscheiden musst, wenn eine Netzwerkpartition deine Nodes trennt. Partitionstoleranz kannst du nicht abwählen, weil Netzwerke ausfallen, ob du damit planst oder nicht. Die eigentliche Frage ist also, was dein System während einer Partition tut: Writes ablehnen, um korrekt zu bleiben, oder sie annehmen und später abgleichen. Außerhalb einer Partition kannst du beides haben, weshalb Latenz der alltägliche Trade ist.

Mein Rahmen ist, dass Partitionstoleranz keine Wahl ist, weil Pakete verloren gehen und Switches ausfallen, egal wie meine Architektur aussieht. CAP fragt also eigentlich, was das System tut, während es geteilt ist: den Write ablehnen, damit niemand veraltete Daten liest, oder den Write annehmen und es danach in Ordnung bringen. Was mir an der PACELC-Erweiterung gefällt, ist, dass sie den Teil benennt, mit dem du täglich zu tun hast, nämlich dass du selbst bei komplett gesundem System Latenz gegen Konsistenz tauschst, weil ein Quorum-Write über Regionen hinweg Round Trips kostet. In einem Produkt, an dem ich gearbeitet habe, haben wir es pro Feature getrennt. Alles rund um Billing lief über den Primary mit einer Read-after-Write-Garantie, weil jemanden doppelt zu belasten sich nicht mit einer Entschuldigung reparieren lässt. Der Activity Feed hat von Replicas gelesen und durfte ein paar Sekunden hinterher sein, und das ist nie jemandem aufgefallen. Gleiches System, zwei Antworten, pro Feature gewählt statt als architektonische Religion.