CAP-теорема — это не только про NoSQL: в распределённых системах на PostgreSQL, таких как кластеры с репликацией или HA-решениями, разработчики сталкиваются с теми же компромиссами между консистентностью, доступностью и устойчивостью к сбоям сети. Понимание этих принципов критично при проектировании отказоустойчивых Rails-приложений и DevOps-инфраструктуры, где выбор между синхронной и асинхронной репликацией может повлиять на надёжность всего сервиса.
Если ты работаешь с PostgreSQL и слышал про CAP-теорему, но думал, что это только про NoSQL — самое время пересмотреть взгляды.
📐 Что такое CAP-теорема?
CAP расшифровывается как:
- C — Consistency (Консистентность)
- A — Availability (Доступность)
- P — Partition tolerance (Устойчивость к разделению сети)
📌 Согласно теореме:
В условиях сетевого разделения невозможно одновременно обеспечить консистентность и доступность.
🧠 Как это связано с PostgreSQL?
В обычной (локальной) установке PostgreSQL у тебя всё хорошо:
✅ Консистентность
✅ Доступность
🚫 Нет разделения сети (оно и не нужно)
Но в момент, когда ты:
- Делаешь репликацию
- Используешь кластер (Patroni, Citus)
- Добавляешь HA (High Availability)
ты входишь в мир распределённых систем.
💣 Пример проблемы CAP в PostgreSQL-кластере
Сценарий:
- У тебя есть master и реплика.
- Сеть падает между ними.
- Реплика становится новым мастером (failover).
- Старая нода возвращается.
Если ты продолжал писать в старого мастера, получаешь рассинхрон и потерю консистентности. Это компромисс между Availability и Consistency.
⚙️ Какие режимы существуют?
| Режим | C | A | P | Пример |
|---|---|---|---|---|
| Single-node | ✅ | ✅ | ❌ | Локальный PostgreSQL |
| Синхронная репликация | ✅ | ❌ | ✅ | Только один мастер |
| Асинхронная репликация | ❌ | ✅ | ✅ | Возможен data loss при сбое |
| etcd + Patroni | 🔁 | 🔁 | ✅ | Баланс зависит от настройки |
🔍 Что делать?
- Понимать, что отказоустойчивость ≠ консистентность
- Использовать logical replication, если тебе нужен контроль
- Настроить Synchronous Commit с quorum — но понимать риски
- Учитывать CAP при выборе архитектуры
📌 Вывод
PostgreSQL — это не просто локальная база. Как только ты начинаешь строить отказоустойчивость, ты вступаешь на территорию CAP-теоремы. И тебе придётся делать выбор: или ты теряешь данные, или ждёшь доступности. Волшебства не бывает — только компромиссы.