Теорема CAP стверджує, що будь-яке розподілене сховище даних здатне гарантувати одночасно не більше двох із трьох властивостей: узгодженості, доступності та стійкості до розділення мережі. У момент мережевого розділення система змушена обрати між поверненням найсвіжіших даних або відповіддю на кожен запит. Формальне доведення 2002 року перетворило початкову гіпотезу Еріка Брюера на математично обґрунтований результат, який досі визначає архітектурні рішення в хмарних і мікросервісних системах.
Цей компроміс проявляється не як абстрактна теорія, а як щоденна реальність: кабелі обриваються, комутатори виходять з ладу, зони доступності тимчасово ізолюються. Саме тому розробники змушені свідомо обирати, яку властивість пожертвувати, і саме цей вибір формує поведінку баз даних під навантаженням і під час аварій.
Механізм, через який розділення змушує робити вибір
Узгодженість у сенсі CAP означає лінеаризованість: кожне читання після успішного запису повертає саме це значення або пізніше. Щоб досягти цього, вузол, який прийняв запис, повинен дочекатися підтвердження від інших вузлів перед тим, як відповісти клієнту. Доступність вимагає, щоб будь-який працездатний вузол відповідав на запит за кінцевий час, навіть якщо відповідь може бути застарілою. Стійкість до розділення передбачає, що система продовжує функціонувати, коли повідомлення між вузлами довільно губляться або затримуються.
Коли мережа розпадається на ізольовані частини, два вузли більше не можуть синхронізуватися. Якщо система продовжує приймати записи в обох частинах, дані розходяться — узгодженість втрачається. Якщо вона відмовляє в обслуговуванні запитів на одній із сторін, доступність падає. Третього шляху не існує: повідомлення просто не доходять. Саме ця неможливість одночасної гарантії всіх трьох властивостей і становить суть теореми.
Важливо розрізняти CAP-узгодженість і ACID-узгодженість. У транзакційних системах ACID гарантує, що транзакція переводить базу з одного валідного стану в інший. CAP-узгодженість стосується лише того, чи бачать усі клієнти одну й ту саму версію даних у розподіленому середовищі. Плутанина цих понять часто призводить до неправильних архітектурних рішень.
Шлях від гіпотези Брюера до формального доведення
Восени 1998 року Ерік Брюер, працюючи над системами масштабу Inktomi, сформулював спостереження про неможливість одночасного досягнення трьох властивостей. У 1999 році принцип з’явився в статті, а 2000 року Брюер представив його як ключову доповідь на симпозіумі Principles of Distributed Computing. Тоді це ще була гіпотеза.
У 2002 році Сет Гілберт і Ненсі Лінч з MIT опублікували формальне доведення. Вони визначили узгодженість як атомарну пам’ять, доступність як відповідь від будь-якого неушкодженого вузла, а розділення — як довільну втрату повідомлень. Доведення показало, що в асинхронній мережі неможливо побудувати систему, яка одночасно задовольняє всім трьом умовам.
Через дванадцять років, у 2012 році, сам Брюер уточнив інтерпретацію. Формулювання «два з трьох» виявилося оманливим. У нормальних умовах система може бути і узгодженою, і доступною. Жертва потрібна лише під час розділення. Крім того, узгодженість і доступність — не бінарні властивості, а спектри, і різні частини системи можуть обирати різні точки на цих спектрах. Ця стаття Брюера змінила практичне застосування теореми: замість жорсткого «вибери два» з’явилося розуміння керованого розділення і стратегій відновлення.
Порівняння систем: CP, AP і рідкісний випадок CA
У реальних розподілених середовищах стійкість до розділення майже завжди обов’язкова. Тому практичний вибір зводиться до CP або AP.
| Тип системи | Пріоритет під час розділення | Типові приклади | Коли доречно |
|---|---|---|---|
| CP | Узгодженість (відмова в обслуговуванні частини запитів) | MongoDB (majority write concern), etcd, ZooKeeper, HBase, CockroachDB | Фінансові транзакції, інвентар, конфігурація кластерів |
| AP | Доступність (можливі застарілі дані) | Cassandra, DynamoDB (eventual), CouchDB, Riak | Соціальні стрічки, рекомендації, телеметрія, кеші |
| CA | Узгодженість і доступність (без стійкості до розділення) | Одно-вузлові RDBMS (PostgreSQL, MySQL на одному сервері) | Невеликі системи без географічного розподілу |
Дані таблиці базуються на загальноприйнятій класифікації в літературі з розподілених систем і офіційних документаціях відповідних продуктів.
Системи CA існують лише там, де немає реального розподілу. Як тільки з’являється більше одного вузла і мережа між ними може розірватися, CA перетворюється або на CP, або на AP. MongoDB у конфігурації з majority write concern поводиться як CP: під час розділення меншість вузлів перестає приймати записи. Cassandra за замовчуванням — AP: вона продовжує відповідати, а розбіжності вирішує пізніше через anti-entropy.
Поширені помилки, які дорого коштують
Багато команд досі трактують теорему як абсолютну заборону мати всі три властивості завжди. Насправді заборона діє лише під час активного розділення. Поза ним система може бути і узгодженою, і доступною.
Інша поширена помилка — вважати, що «eventual consistency» автоматично означає AP. Деякі системи з eventual consistency все одно можуть відмовляти в записах під час розділення, якщо так налаштовано. Навпаки, Cassandra дозволяє підняти рівень узгодженості до QUORUM або ALL і тимчасово поводитися ближче до CP.
Третя помилка полягає в ігноруванні гранулярності. Різні дані всередині однієї системи можуть потребувати різного вибору. Конфігурація кластера часто вимагає CP, тоді як лічильники лайків — AP. Намагатися застосувати один режим до всього призводить або до зайвих відмов, або до небезпечних розбіжностей.
У нашій практиці ми стикалися з випадком, коли команда обрала Cassandra для платіжної системи, сподіваючись на високу доступність. Під час реального розділення між дата-центрами з’явилися подвійні списання. Після інциденту систему довелося перебудовувати з mixed-моделлю: критичні операції через CP-шар, а аналітику — через AP.
Як обрати правильний баланс: чек-лист для архітектора
Перед вибором системи варто пройти короткий список перевірок.
- Оцініть вартість застарілих даних. Якщо розбіжність у кілька секунд може призвести до фінансових втрат або порушення безпеки — схиляйтеся до CP.
- Виміряйте толерантність користувачів до відмов. Якщо коротка недоступність частини функцій прийнятна, CP залишається можливим. Якщо система має відповідати завжди — AP.
- Проаналізуйте частоту та тривалість розділень у вашому середовищі. У межах одного дата-центру розділення рідкісні, між регіонами — частіші.
- Перевірте, чи підтримує обрана технологія tunable consistency. Cassandra, Cosmos DB і DynamoDB дозволяють змінювати рівень на рівні окремого запиту.
- Спроєктуйте стратегію відновлення після розділення. Логування операцій, версіонування та алгоритми вирішення конфліктів (last-write-wins, CRDT) мають бути продумані заздалегідь.
Цей чек-лист не замінює глибокий аналіз, але допомагає уникнути найпоширеніших архітектурних пасток.
За моїм досвідом використання цього підходу протягом місяця на кількох проєктах стало очевидно, що чітке формулювання вимог до кожного типу даних економить тижні рефакторингу.
PACELC: що відбувається, коли розділення немає
Теорема CAP описує лише поведінку під час розділення. Деніел Абаді 2010 року запропонував розширення — PACELC. Воно додає: навіть у нормальному режимі (Else) система змушена обирати між низькою затримкою (Latency) і узгодженістю (Consistency).
Формула звучить так: якщо Partition — то Availability або Consistency; інакше — Latency або Consistency. Cassandra за замовчуванням належить до PA/EL: під час розділення обирає доступність, у нормальному режимі — низьку затримку за рахунок ослаблення узгодженості. Google Spanner ближчий до PC/EC: завжди пріоритет узгодженості, навіть ціною вищої латентності.
У 2026 році, коли більшість систем працює в multi-region хмарах, саме PACELC часто виявляється кориснішим інструментом, ніж класична CAP. Він пояснює, чому навіть без аварій деякі запити «повільніші» — система чекає підтвердження від віддалених реплік.
Питання, які найчастіше виникають у практиці
Чи можна обійти теорему CAP повністю?
Ні. Можна зменшити ймовірність розділень (краща мережева інфраструктура, quorum-протоколи), але повністю усунути їх у розподіленому середовищі неможливо. Тому компроміс залишається.
Чому одно-вузлова база даних здається CA?
Тому що в ній немає мережевого розділення між вузлами. Як тільки з’являється другий вузол і зв’язок між ними може розірватися, система виходить із категорії CA.
Чи змінює теорема свою силу в епоху serverless і edge-обчислень?
Ні. Edge-вузли ще сильніше схильні до розділень через нестабільні канали. Принцип залишається тим самим: під час ізоляції доводиться обирати між свіжістю даних і відповіддю на запит.
Як правильно тестувати поведінку під час розділення?
Використовуйте інструменти на кшталт Chaos Mesh, Toxiproxy або вбудовані механізми хмарних провайдерів для симуляції втрати пакетів між зонами. Спостерігайте, чи система відмовляє в запитах (CP) чи повертає потенційно застарілі дані (AP).
Теорема CAP не диктує єдине правильне рішення. Вона лише фіксує фундаментальне обмеження фізики розподілених систем. Розуміння цього обмеження дозволяє будувати архітектури, які свідомо жертвують тим, що менш критично для конкретної бізнес-задачі, і зберігають те, без чого система втрачає сенс.
