CAP теорема на собеседовании системного аналитика
Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.
Содержание:
Зачем спрашивают
Любая распределённая система — банк, маркетплейс, госуслуги — построена с учётом trade-off между корректностью и доступностью. Системный аналитик пишет в ТЗ: «при недоступности одного узла система должна продолжать обслуживание». На собесе спросят, что это значит на практике и что мы теряем.
Главная боль без CAP — аналитик пишет «всегда строгая согласованность всех узлов», команда строит синхронную репликацию, при сетевом сбое полсистемы недоступна. Бизнес теряет деньги, и аналитик идёт переписывать ТЗ.
CAP — концептуальная база для разговора об архитектуре. На собесе SA спрашивают почти всегда middle-уровень.
Три свойства CAP
Consistency (согласованность). Все узлы видят одинаковые данные одновременно. Запись на узле A сразу же доступна на B. В CAP это linearizable consistency (строгая), не «consistency» из ACID.
Availability (доступность). Каждый запрос получает ответ (не ошибку). Без гарантий, что данные самые свежие.
Partition tolerance (устойчивость к разделению). Система продолжает работать при потере связности части узлов.
Теорема Брюера (2000): в любой распределённой системе нельзя одновременно гарантировать все три. При сетевом разделении (Partition) приходится выбирать между Consistency и Availability.
В реальности Partition неизбежен — сети рвутся, узлы падают. Поэтому CAP — это выбор между CP (consistency при разделении, availability жертвуем) и AP (availability при разделении, consistency жертвуем).
CP, AP, CA: что выбрать
CP-системы: при разделении блокируют операции, чтобы не отдавать неактуальные данные.
- HBase, MongoDB (с majority writes), Postgres с синхронной репликацией, ZooKeeper, etcd
Кейсы: банковские балансы, медицинские записи, юридические документы, координация (lock service).
AP-системы: при разделении продолжают принимать запросы, потенциально расходясь — потом сходятся (eventual consistency).
- Cassandra, DynamoDB (с low consistency), CouchDB, Riak
Кейсы: ленты соцсетей, каталоги товаров, DNS, метрики и счётчики, S3.
CA-системы: не существует в распределённой среде. Если есть несколько узлов — сеть когда-то порвётся, и нужно выбрать. CA = «один узел», то есть нераспределённая БД. Sometimes одиночный Postgres называют «CA», потому что нет распределения.
Тонкость: CAP формулируется только во время разделения. В нормальной работе можно иметь и C, и A. Большинство реальных систем настраиваются: «обычно C+A, во время разделения склоняется к одной из сторон».
BASE и eventual consistency
BASE (basically available, soft state, eventual consistency) — альтернатива ACID для AP-систем.
- Basically Available — система отвечает (даже устаревшими данными)
- Soft State — состояние может меняться без явного запроса (background репликация)
- Eventual Consistency — после прекращения изменений все реплики сойдутся к одному состоянию
Eventual consistency на практике — секунды. Запись в Cassandra пришла в один регион, через 50–500 мс реплицировалась во все. Читатель из другого региона может в этот момент увидеть старую версию.
Read your own writes — гарантия, что после своей записи клиент видит её на следующем чтении. Реализуется через session affinity (читать с того же узла, куда писали) или quorum reads/writes.
Quorum: N реплик, W = quorum write, R = quorum read. Если R + W > N — гарантия, что чтение увидит хотя бы одну реплику с последней записью. Cassandra: N=3, W=2, R=2 → consistent при условии этого правила.
Примеры распределённых БД
| БД | Тип | Заметки |
|---|---|---|
| Postgres (single) | CA (по сути) | Один узел, не распределена |
| Postgres + sync replica | CP | Sync replication: master ждёт slave |
| MongoDB (W=majority) | CP | majority write, primary down → reelection |
| Cassandra | AP | Eventual, настраиваемая через quorum |
| DynamoDB | Настраиваемая | Strong / eventual consistency на запрос |
| HBase | CP | Master + Region Servers, no partition tolerance в чтении |
| Redis Cluster | AP | Master/replica, при split — может потерять записи |
| Etcd / ZooKeeper | CP | Raft / ZAB consensus, used для конфигов и locks |
| Spanner | CP+ | Atomic clocks, low-latency consistency на глобальных распределениях |
На собесе классический кейс: «MongoDB — CP или AP?» Правильный ответ: «По умолчанию CP с majority write concern. Можно настроить acknowledged=1 для AP-поведения. Зависит от write concern».
PACELC: расширение CAP
PACELC (Daniel Abadi, 2010) — более полная модель:
- Partition: при разделении выбираем Availability или Consistency
- Else (нормальная работа): trade-off между Latency и Consistency
Большинство систем имеют trade-off и в нормальной работе: строгая consistency требует ожидания подтверждения от других узлов = латентность.
| Система | PACELC |
|---|---|
| Spanner | PC/EC (CP при разделении, EC = consistency over latency) |
| Cassandra | PA/EL (AP, eventual consistency, low latency) |
| MongoDB | PA/EC (AP в дефолте, но строгий read concern) |
| Redis | PA/EL (eventual между master/replica) |
PACELC — продвинутый ответ на собесе. В РФ достаточно знать CAP; если знаешь PACELC — плюс.
Частые ошибки
«Спроектируем для CA». Если система распределённая — CA не вариант. Нужно сразу решать CP или AP.
Считать eventual consistency = «сломано». Это не баг. Большинство соцсетей, маркетплейсов работают на eventual consistency. Главное — описать в ТЗ, что временное расхождение допустимо.
Игнорировать write concern / consistency level. В MongoDB/Cassandra настройка влияет на гарантии. Аналитик должен описать в ТЗ: «писать с majority concern», «читать с quorum».
Применять ACID-привычки к распределённым системам. Distributed transactions через 2PC — медленно, fragile. Saga, event-sourcing — более подходящие паттерны.
Не учитывать стоимость consistency. Каждое подтверждение от удалённого узла = сетевой round-trip = десятки миллисекунд. Для real-time interactive UI — иногда нельзя.
Считать CAP «выбором архитектуры». CAP — про trade-off, который проявляется только при разделении. В нормальной работе можно иметь и то, и другое.
Применять «AP во всё». Деньги, контракты, платежи — где допустим только consistency. AP в банковских балансах = двойное списание.
Связанные темы
- ACID и уровни изоляции на собесе SA
- Подготовка к собесу системного аналитика
- Сoбеседование системного аналитика
- REST API на собесе SA
- SQL vs NoSQL: когда что
FAQ
Кто доказал CAP?
Eric Brewer сформулировал в 2000 (CAP conjecture). Доказали Gilbert и Lynch в 2002.
MongoDB — CP или AP?
С writeConcern: majority и readConcern: majority — CP. С writeConcern: 1 — ближе к AP. По умолчанию в новых версиях стремится к CP-поведению.
Чем sharding отличается от replication в контексте CAP?
Sharding — разделение данных. Replication — копии данных. CAP применима к replication (несколько копий → возможно расхождение). Sharding сам по себе не порождает CAP-trade-off, но в распределённых системах обычно идут вместе.
Как объяснить CAP в ТЗ?
«Система остаётся доступной для чтения при отказе одного узла; в момент рассинхронизации возможна задержка распространения изменений до 5 секунд (eventual consistency)» — пример AP-формулировки. Для банка: «при недоступности master запись блокируется до восстановления (CP)».
Что такое split-brain?
Сетевое разделение, при котором несколько узлов считают себя master одновременно. На AP-системах — допустимо, на CP — fence-mechanism (quorum, leader election) предотвращает.
Это официальная информация?
Нет. Статья основана на CAP theorem (Brewer 2000, Gilbert-Lynch 2002), PACELC (Abadi 2010) и документации NoSQL-БД.
Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.