cap-theorem.js·3 scenarios
CAP-теорема и модели консистентности. CP vs AP под partition, session consistency, PACELC.
CAP-теорема — формальная классификация: при сетевом разделении распределённая система может быть либо консистентной (CP), либо доступной (AP), но не одновременно. P (partition tolerance) обязательна — сеть всегда может развалиться.
Разрыв сети ставит систему перед выбором: отказать или соврать.
CP-системы (банкинг, лидер-выборы, кворумные базы вроде etcd/ZooKeeper) предпочтут вернуть ошибку, чем закоммитить write без подтверждения большинства реплик. Это «отказать».
AP-системы (Cassandra с consistency=ONE, DynamoDB eventually consistent, social feeds) отдадут устаревшее значение, чтобы оставаться доступными. Потерянные обновления догонят через replication lag. Это «соврать (временно)».
Session consistency — частичный компромисс: клиент видит свои собственные writes (через version-токен), но не обязательно writes других пользователей. Полезно для UX: ты опубликовал пост → видишь его сразу, даже если другие пользователи увидят с задержкой.
CP, когда:
AP, когда:
Не путайте CAP с трейд-оффом latency-vs-consistency в нормальной работе (без partition). PACELC — расширение: when Partitioned, choose A or C; else (нормально), choose Latency or Consistency. Большинство «AP-систем» в стабильной сети могут давать сильную консистентность за счёт большей latency — настоящий выбор только при partition.