CAP-теорема и компромиссы

при сетевом разделении система может выбрать только согласованность или доступность, но не оба.

Почему это важно: Без понимания CAP инженеры выбирают БД и архитектуру по моде, а не по требованиям к согласованности и доступности.

Network partitions неизбежны — выбирайте, что важнее: ответить устаревшими данными или не ответить вовсе.

В кластере БД произошёл сетевой раздел: ноды не видят друг друга.
CP-система (Postgres с синхронной репликацией) — отказывает в записи на split node.
AP-система (DynamoDB) — продолжает принимать запись, но данные могут разойтись.
Восстановление сети требует разрешения конфликтов в AP-системе.

Типичные ошибки и заблуждения

Ошибка: CAP — это про обычные работающие системы. Это про поведение во время split brain.
Ошибка: можно получить все три. Сетевые разделы случаются, и тогда выбор обязателен.
Ошибка: NoSQL = AP всегда. DynamoDB поддерживает strong consistency для некоторых операций.
Ошибка: SQL = CP всегда. С асинхронной репликацией Postgres может стать AP.

Consistency: все ноды видят одинаковое состояние.

Availability: каждый запрос получает ответ.

Partition tolerance: устойчивость к сетевым разделам.

Split brain: ситуация, когда разделённые ноды считают, что они главные.

CAP — это инструмент мышления, а не школьная теорема. Без него невозможно осознанно выбирать БД и архитектуру для распределённых систем.

Команда выбрала AP-БД 'для скорости' и обнаружила, что счета банковских клиентов могут расходиться при отказах сети. Пришлось менять архитектуру.

CAP-теорема — точка отсчёта в проектировании распределённых данных. Игнорировать её — значит обрекать систему на сюрпризы при первом сбое сети.

Комментарии к уроку