PostgreSQL — мощная СУБД, но в распределённых системах она сталкивается с теми же вызовами, что и NoSQL-решения: CAP-теорема диктует выбор между доступностью и консистентностью, а PACELC уточняет компромиссы при работе в штатном режиме. Понимание этих принципов критично для проектирования отказоустойчивых кластеров и репликации в Rails-приложениях.
Скажи честно — ты думал, что CAP — это про MongoDB? Или Cassandra?
Но даже любимый PostgreSQL попадает под эту теорему, стоит только добавить HA и кластер.
🛠 Когда CAP становится важен
- У тебя Patroni, pg_auto_failover или репликация через streaming
- Сеть — это не localhost
- Доступность важна, но ты не хочешь потерять данные
Тут начинается выбор: доступность или консистентность?
🔁 А если всё работает?
Вот тут и вступает PACELC.
Синхронная репликация тратит миллисекунды на подтверждение — ты жертвуешь Latency ради Consistency.
Асинхронная — быстро, но возможна потеря.
📌 Вывод
Даже PostgreSQL не спасёт от законов распределённых систем.
CAP и PACELC — это не страшилки, а руководство к проектированию.