CAP и инженерные компромиссы

CAP утверждает: в условиях разделения сети (Partition, P) распределенная система не может одновременно гарантировать и сильную согласованность (Consistency, C), и доступность (Availability, A). При наличии P приходится выбирать либо CP, либо AP. В отсутствие разделений ограничение не действует, но появляются другие компромиссы — прежде всего задержка (latency) и стоимость.

Практическая инженерия выходит за пределы CAP: важны PACELC (если P — выбираем C или A; иначе — выбираем между Latency и Consistency), модели согласованности, SLA/SLO, юзкейсы и риски бизнеса.

1) Базовые определения (без философии)

Согласованность (C): все клиенты видят один и тот же результат «как будто» операции выполнялись последовательно (линейризуемость/strong consistency).
Доступность (A): каждый запрос к неупавшему узлу завершается ответом в разумное время, даже при разделении.
Разделение (P): потеря или значительная деградация связи между узлами/региональными кластерами; по сути — «неизбежно» в большом масштабе.
PACELC: при P выбираем C или A; else (когда P нет) выбираем L (низкую задержку) или C (сильную согласованность).

2) Интуитивная картинка выбора

CP (согласованность важнее): при разделении часть запросов отклоняем/блокируем, чтобы не нарушить инварианты. Подходит для денег, транзакций, учета остатков.
AP (доступность важнее): отвечаем всегда, но допускаем временную рассогласованность, затем схлопываем конфликты (CRDT/правила мерджа). Подходит для соц-фидов, счетчиков лайков, кешированных профилей.
CA (одновременно C и A): возможно только в отсутствие P — то есть пока сеть здорова. В реальной эксплуатации «CA» — временное состояние, а не свойство дизайна.

3) PACELC: не забываем про задержку

• Сильная консистентность между регионами = межконтинентальные кворумы ⇒ десятки–сотни мс к p95.
• Локальные чтения (низкая L) = более слабые гарантии (read-my-writes, bounded staleness, eventual).
• PACELC помогает объяснить, почему «быстро и строго» глобально — редкость: свет — не мгновенный, а кворумы растут со складностью сети.

4) Модели согласованности (быстрый спектр)

Linearizable / Strong: как будто один последовательный порядок.
Serializable: эквивалентно некоторому последовательному порядку транзакций (выше уровня записей).
Read-your-writes / Monotonic reads: клиент после собственной записи читает новое значение.
Bounded staleness: чтения отстают не больше N версий/Δt.
Eventual consistency: со временем все копии сходятся; конфликты нужно разрешать.

5) Паттерны CP и AP в продуктах и протоколах (концептуально)

CP-подходы: кворумные журналы/лидерство (Raft/Paxos), строгие транзакции, глобальные локации лидера, синхронная репликация. Цена — отказ части запросов при P и рост задержек.
AP-подходы: мульти-мастер/мульти-лидер, CRDT, gossip-распространение, асинхронная репликация, разрешение конфликтов (LWW, векторные часы, доменные мердж-функции). Цена — временная рассогласованность и сложность доменных правил.

6) Компромиссы в мульти-регионе

Глобальный лидер (CP): простая логика, но «дальние» регионы платят латентностью; при P — блокировка записей.
Локальные лидеры + асинхрон (AP): запись быстрая локально, затем репликация; конфликтующие изменения требуют мерджа.
Geo-partitioning: данные «живут» ближе к пользователю/юрисдикции; кросс-регион — только агрегаты.
Dual-write запрещен без саг/CRDT: иначе получаются фантомы и двойные списания.

7) Инженерные инварианты и бизнес-решения

Сначала инварианты: что никогда нельзя нарушать (двойной расход, отрицательный остаток, уникальность ключа), а что «переживает» eventual (счетчик просмотров, рекомендации).

• Инвариант «жесткий» → CP для соответствующих операций.
• Инвариант «мягкий» → AP с последующим схлопыванием.

8) Техники смягчения компромиссов

Кэш и CQRS: чтения через близкий кэш/проекции (AP), записи — в строгий журнал (CP).
RPO/RTO как язык компромисса: сколько данных можно потерять (RPO) и как быстро восстановиться (RTO).
Согласованные ID и часы: монотонные таймстампы (Hybrid/TrueTime-подходы), ULID/Snowflake.
Саги/TCC: бизнес-компенсации вместо глобальных блокировок.
CRDT и доменный мердж: для коллекций, счетчиков, «последних побед».
Bounded staleness: баланс UX и точности.

9) Наблюдаемость, SLO и управление инцидентами

SLO по латентности (p50/p95/p99) отдельно для чтений/записей и регионов.
SLO по доступности с учетом фейловера региона.
Lag репликаций/конфликтность: доля конфликтов, среднее время разрешения.
Алерты по признаком P: всплеск таймаутов межрегиональных каналов, рост ошибок кворума.
Degrade-планы: read-only режим, локальное обслуживание с последующим мерджем, отключение «дорогих» функций.

10) Чек-лист выбора стратегии

1. Какие инварианты нельзя нарушать? Что допускает eventual?
2. Нужен ли кросс-региональная запись с низкой латентностью?
3. Каковы целевые SLO (латентность/доступность) и стоимость (egress/репликации)?
4. Допускаете ли manual merge или только автомат (CRDT/правила)?
5. Каков профиль отказа сети: частота, длительность, blast radius?
6. Есть ли юридическая локализация данных (residency)?
7. Какая модель согласованности приемлема для каждого типа данных/операции?
8. Как будете наблюдать: лаги, конфликты, состояние кворумов?
9. Что делает система при P: блокирует, деградирует, разделяет трафик?
10. Какой план восстановления и репатриации данных после P?

11) Типичные ошибки

Погоня за «CA навсегда». При первом же P придется выбирать — лучше заранее.
Глобальный мульти-мастер без правил мерджа. Конфликты «съедают» данные и доверие.
Сильная консистентность «повсюду». Избыточные кворумы бьют по p95/p99 и бюджету.
Dual-write без транзакций/саг. Потерянные инварианты и фантомы.
Игнорирование PACELC. В мирное время страдает латентность, в шторм — доступность.
Нулевая телеметрия конфликтов и лагов. Проблемы видны только пользователю.

12) Быстрые рецепты

Платеж/баланс: CP-хранилище с кворумами; записи только через лидера; чтения могут быть кэшированы, но в критичных UX — read-your-writes.
Контент/фид: AP-репликация + CRDT/правила мерджа; при P — обслуживать локально, потом схлопывать.
Глобальный SaaS: geo-partitioning по `tenant/region`; строгие операции в «домашнем» регионе (CP), отчеты/поиск — через асинхронные проекции (AP).
Реал-тайм сигналинг: Anycast/edge + AP-шина; критичные команды проходят через подтвержденный канал (CP).
Аудит/журнал: единственный источник истины (append-only) с CP-гарантиями, вокруг — кэши и проекции.

13) Мини-эталон архитектуры (словесно)

Write-core (CP): лидер + кворумная репликация, строгие инварианты, саги для межсервисных эффектов.
Read-plane (AP): материализованные представления, кэши, search-индексы, асинхронное обновление.
Geo-routing: пользователи попадают в «домашний» регион; при P — локальный режим + последующая репликация.
Конфликт-движок: CRDT/правила; журнал конфликтов и средства ручного урегулирования.
Наблюдаемость: трейсинг кворумов, лаги, карта инцидентов сети.

14) Практическая математика задержек (простая оценка)

Оптика ≈ 5 мс на 1000 км (RTT еще больше). Межконтинентальные кворумы → p95 легко > 150–250 мс.
Любой «глобальный Strong» для записи — это дорогой запрос. Если UX требует <100–150 мс, подумайте о локальном write-home + асинхронных последствиях.

15) Политики на случай разделений

CP-путь: блокировать записи вне кворума; включать read-only; отдавать честные статусы пользователю.
AP-путь: обслуживать локально; маркировать версии; при восстановлении — детерминированный мердж; конфликты поднимать в очередь разбора.

Заключение

CAP — не догма, а напоминание: разделения сети неизбежны, и проект должен заранее выбрать, чем жертвовать в шторм — доступностью или строгой согласованностью. PACELC добавляет ключевую ось задержки в ясную погоду. Комбинируйте стратегии: держите CP-ядро там, где инварианты священны, и AP-плоскость там, где важнее скорость и устойчивость. Закладывайте телеметрию, планы деградации и процессы мерджа — и система сохранит и данные, и пользовательское доверие.