BASE

BASE (Basically Available, Soft state, Eventually consistent) — подход к проектированию распределённых систем
Жертвует строгой согласованностью (ACID) ради доступности, масштабируемости и гибкости. У систем BASE может не быть четкого состояния, в отличие от ACID

Когда используют

NoSQL-системы (Cassandra, MongoDB, DynamoDB)
Высоконагруженные сервисы (соцсети, аналитика)
Системы, где важнее скорость ответа и отказоустойчивость, чем мгновенная актуальность данных

Три принципа

Basically Available (базовая доступность)

Система всегда отвечает, даже при частичных сбоях
Данные могут быть неактуальными, но запросы не блокируются

Как достигается:

Репликация (копирование данных на несколько узлов)
Шардирование (например, данные делятся между кластерами)
Кэширование

Soft State (гибкое состояние)

Данные могут меняться со временем без внешних запросов
И могут временно находиться в несогласованном состоянии из-за асинхронных обновлений

Асинхронная синхронизация
TTL (время жизни данных, например кэш обновляется раз в 5 минут)
Фоновые процессы согласования

Eventually Consistent (окончательная согласованность)

Система придет к согласованности, но не мгновенно

Конфликт-разрешающие алгоритмы (Conflict-free Replicated Data Types, Last-Write-Win)
Подтверждение записи от большинства узлов (например, в Cassandra)
Исправление устаревших данных при последующих чтениях
Kafka или RabbitMQ с отложенной синхронизацией

BASE vs ACID vs CAP

ACID — как банковский перевод: либо деньги ушли и пришли полностью, либо операция отменена
Для систем, где важна точность (платежи, бухгалтерия)

BASE — как почта: письмо точно ушло, но когда дойдёт — неизвестно

БД не может быть и ACID, и BASE одновременно. Это противоположные подходы
Но некоторые гибридные СУБД (например, MongoDB) позволяют гибко настраивать уровень согласованности

CAP — определяет фундаментальные ограничения распределённых систем
BASE — практический подход в рамках этих ограничений

CAP-теорема говорит, что система может гарантировать только 2 из 3 свойств:

Согласованность (Consistency)
Доступность (Availability)
Устойчивость к разделению (Partition tolerance)

ACID выбирает CP (согласованность + устойчивость)
BASE - AP (доступность + устойчивость)
CA-системы (консистентность и доступность) возможны только в нераспределенных системах

Пример реализации BASE

Онлайн-магазин с высокой нагрузкой

B: Пользователь добавляет товар в корзину → система сразу подтверждает действие, даже если часть серверов перегружена
Товар мгновенно появляется в корзине у пользователя, но остатки на складе могут обновиться с небольшой задержкой

Отправка запроса → API сразу возвращает успех (202 Accepted)

S: Данные о корзине и об остатках лежат в разных сервисах
Если два покупателя одновременно добавляют последний товар → оба увидят его в корзине, но физически доступен только 1

Сервис корзин (Redis) временно сохраняет изменения
Сервис склада (Kafka + PostgreSQL) асинхронно проверяет остатки

E: Через несколько сек система проверяет остатки и синхронизирует данные

Если товара нет, система убирает его из корзины и отправляет уведомление

В ACID система заблокировала бы остатки при добавлении в корзину -> очереди и ошибки под нагрузкой
BASE позволяет сначала принять действие, потом проверить ограничения. Это критично для высоконагруженных сценариев

BASE в EDA (Event-Driven Architecture)

Возможен из-за асинхронного типа событий

Механизмы реализации

Event Sourcing (Хранение событий как источника истины)
Сохраняется вся последовательность событий, а не текущее состояние

Пример: для заказа хранится не просто "статус: оплачен", а цепочка: "создан" → "передан в оплату" → "оплата подтверждена"

Можно легко восстанавливать состояние после сбоев и анализировать историю изменений
Реализуется через специальные БД (EventStoreDB) или через обычные (Kafka+PostgreSQL)

CQRS (Command Query Responsibility Segregation)
Разделение на 2 независимых компонента:

Командная часть (Write Model):

Принимает команды изменения состояния
Генерирует события
Оптимизирована для записи

Чтение (Read Model):

Строит проекции данных для быстрого чтения
Может отставать от командной части (eventual consistency)
Оптимизирована под конкретные запросы UI

Saga Pattern (Оркестрация длительных процессов)
Механизм для управления распределенными транзакциями

Хореография:

Каждый сервис самостоятельно реагирует на события
Нет центральной точки управления
Пример: Сервис оплаты сам решает, когда проводить транзакцию после получения OrderCreated

Оркестрация (через центральный координатор):

Координатор отправляет команды сервисам
Легче отслеживать, но есть зависимость от координатора

Outbox Pattern (Надежная публикация событий)
Решение проблемы "двойной записи":

Сначала изменения сохраняются в локальную БД вместе с событием в таблицу Outbox
Отдельный процесс забирает события из Outbox и публикует в брокер
Только после успешной публикации событие помечается как отправленное

BASE-транзакционность в EDA

Напомним, атомарное изменение - операция, которая выполняется как единое целое: либо полностью успешно, либо полностью откатывается, без промежуточных состояний. Ключевое свойство ACID-транзакций.

В BASE-транзакционности:

Нет единой блокирующей транзакции
Вместо атомарного изменения компромисс: каждый сервис фиксирует его локально, затем согласованность достигается через события
Это позволяет строить высоконагруженные отказоустойчивые системы

Плюсы и минусы BASE

Плюсы:

Легко добавлять узлы (например, серверы)
Система работает при сбоях (YouTube показывает видео при аварии дата-центра)
Не нужно ждать подтверждения от всех узлов (лайки в соцсетях ставятся мгновенно)

Минусы:

Нужно учитывать временные нестыковки (корзина в интернет-магазине может показывать устаревший остаток)
При аварии возможна потеря последних данных (неподтверждённые данные могут исчезнуть)
Не подходит для операций, где важна точность

Материалы

Видео

Книги

Базы данных. Инжиниринг надежности - Кэмпбелл Лейн, Мейджорс Черити (Глава 11. BASE)

Когда используют​

Три принципа​

Basically Available (базовая доступность)​

Soft State (гибкое состояние)​

Eventually Consistent (окончательная согласованность)​

BASE vs ACID vs CAP​

Пример реализации BASE​

BASE в EDA (Event-Driven Architecture)​

Механизмы реализации​

BASE-транзакционность в EDA​

Плюсы и минусы BASE​

Материалы​

Видео​

Книги​