CAP theorem и PACELC¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

CAP в модели сетевого partition запрещает одновременно обеспечить linearizable consistency и availability каждого запроса к неотказавшему узлу. Availability здесь — формальное завершение операции, не процент uptime/SLA. Partition — возможность потери/задержки сообщений, а не table partitioning.

flowchart LR
  Partition[Network partition] --> Coordinate[Require cross-node agreement]
  Partition --> Local[Answer using local state]
  Coordinate --> Wait[May reject or wait]
  Local --> Stale[May sacrifice linearizability]

Операция чтения или записи по шагам¶

Два узла изолированы: A принимает balance change, B получает read. B либо не отвечает успешным актуальным значением до coordination, либо отвечает без знания A и рискует нарушить linearizability. Таймаут не позволяет достоверно отличить погибший узел от очень медленной сети.

Консистентность, отказ и восстановление¶

PACELC добавляет trade-off latency/consistency при отсутствии partition: remote quorum может повышать задержку даже в здоровой сети. Это полезная классификация решений, но не полный transaction contract. Выбор может различаться для reads/writes, tables и configured consistency mode.

Выбор, эксплуатация и ограничения¶

Для денежных команд предпочтение определяет business invariant и допустимость отказа/очереди; для fraud feature cache можно допустить stale value с явной degrade policy. Нельзя навесить вечную CP/AP метку на продукт с несколькими режимами, например DynamoDB MREC/MRSC или Cassandra CL.

Типичные ошибки проектирования¶

Трактовать CAP как «выбрать любые два из трёх постоянно»; путать ACID consistency с CAP consistency. Вопрос: высокий uptime доказывает CAP availability? Нет, определения и failure model различаются.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Опишите два API одного sportsbook: debit wallet и прочитать odds cache. Для network split задайте ответ, retry/idempotency и последствия stale data без выдуманного SLA.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.