CAP-теорема
Тема дорожной карты · Backend разработчик
Теорема CAP, сформулированная Эриком Брюэром, утверждает, что распределённое хранилище данных может одновременно гарантировать не более двух из трёх свойств: согласованность (Consistency, каждое чтение получает самую актуальную запись), доступность (Availability, каждый запрос получает ответ) и устойчивость к разделению (Partition Tolerance, система продолжает работать несмотря на сетевые разделения). Теорема CAP — фундаментальная концепция для бэкенд-архитекторов, выбирающих между NoSQL базами данных и проектирующих распределённые системы, способные выживать при реальных сетевых сбоях. MongoDB и Cassandra часто описываются как AP-системы по умолчанию — они приоритизируют доступность и устойчивость к разделению, принимая итоговую согласованность, — тогда как традиционные реляционные базы данных вроде PostgreSQL тяготеют к CP-поведению. Elasticsearch также функционирует как AP-система, что важно учитывать при анализе лага репликации при использовании его совместно с авторитетными источниками истины PostgreSQL или MySQL. Применение теоремы CAP на практике означает выбор правильной модели согласованности (strong, eventual, causal) для каждого микросервиса и соответствующую настройку стратегий репликации и шардинга баз данных для соблюдения SLA без ущерба для отказоустойчивости.
Как это работает
CAP-теорема покрывает document (MongoDB, CouchDB), key-value (Redis, DynamoDB, etcd), wide-column (Cassandra, HBase, ScyllaDB), graph (Neo4j, ArangoDB), search (Elasticsearch, OpenSearch). Каждая торгует ACID-гарантиями за конкретное свойство производительности или масштаба. Redis — универсальный швейцарский нож в памяти (кеш, очередь, pub/sub, distributed lock). Elasticsearch доминирует в full-text. MongoDB подходит для гибких JSON-данных, но требует дисциплины денормализации.
Когда применять
Redis — для кеша + rate limit + простых очередей: окупается в большинстве стеков. Elasticsearch / OpenSearch — когда нужен full-text за пределами LIKE %x%. MongoDB или DynamoDB — только если access-паттерн реально не ложится в реляционную модель (высокая частота записи на айтем, очень разнородные документы). Избегайте NoSQL "ради масштаба" до измерения боттлнека в Postgres — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки CAP-теорема: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.