Что такое CAP theorem на практике: реальные компромиссы в системах

CAP theorem — это одно из базовых понятий в распределённых системах. Оно говорит: в случае сетевых проблем система может гарантировать только два из трёх свойств — Consistency, Availability и Partition tolerance.

Важно: в реальной жизни выбирать приходится не «любые два из трёх», а почти всегда между Consistency и Availability, потому что Partition tolerance обязательна.

Три свойства CAP

Consistency (согласованность)

Все клиенты видят одинаковые данные в один момент времени.

Пример:

• вы записали значение в базу
• следующий запрос сразу возвращает новое значение

Availability (доступность)

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

Важно: ответ может быть не самым свежим.

Partition tolerance (устойчивость к разделению)

Система продолжает работать, даже если сеть разделилась на части (partition).

Пример:

• дата-центры потеряли связь друг с другом
• система всё равно обрабатывает запросы

Почему Partition tolerance нельзя игнорировать

В распределённых системах сетевые проблемы — это норма:

• потери пакетов
• задержки
• разрывы соединений

Поэтому любая реальная система должна быть устойчива к partition. Это автоматически оставляет выбор:

• CP (Consistency + Partition tolerance)
• AP (Availability + Partition tolerance)

CP системы

CP системы выбирают согласованность.

Поведение:

• если нет уверенности в актуальности данных — система может не отвечать
• лучше не ответить, чем вернуть устаревшие данные

Примеры:

• базы с сильной консистентностью (например, классические SQL в режиме репликации с quorum)

Плюсы:

• нет «грязных» данных
• предсказуемость

Минусы:

• возможны ошибки или таймауты при проблемах в сети

AP системы

AP системы выбирают доступность.

Поведение:

• система отвечает всегда
• но данные могут быть устаревшими

Примеры:

• распределённые key-value хранилища
• кэши

Плюсы:

• высокая доступность
• устойчивость к сетевым проблемам

Минусы:

• возможна eventual consistency
• требуется разрешение конфликтов

Eventual consistency

В AP системах часто используется модель eventual consistency:

• данные могут отличаться на разных нодах
• со временем они синхронизируются

Пример:

• вы обновили профиль
• часть пользователей видит старую версию
• через секунды/минуты данные выравниваются

Реальные компромиссы

1. Банковские операции

Требования:

• высокая точность
• нельзя терять деньги

Выбор: CP

• лучше отказать, чем провести некорректную операцию

2. Социальные сети

Требования:

• высокая доступность
• задержки допустимы

Выбор: AP

• можно показать старый лайк или комментарий

3. Кэширование

Кэш почти всегда AP:

• данные могут устаревать
• главное — быстрый ответ

4. DNS

DNS — классический пример AP:

• записи кэшируются
• изменения распространяются со временем

Гибридные подходы

Современные системы часто комбинируют подходы:

• strong consistency для критичных данных
• eventual consistency для второстепенных

Пример:

• заказ в интернет-магазине (CP)
• рекомендации товаров (AP)

Влияние на архитектуру

CAP напрямую влияет на:

• выбор базы данных
• стратегию репликации
• обработку ошибок

Инженер должен понимать:

• где допустима задержка
• где важна точность

Итог

CAP theorem — это не теория ради теории, а практическое руководство по проектированию систем.

• Partition tolerance — обязательна
• выбор идёт между Consistency и Availability

Если упрощать:

• CP — «лучше не ответить, чем ошибиться»
• AP — «лучше ответить, даже если данные не идеальны»

Правильный выбор зависит от бизнес-требований, а не от технологии.