Архитектура

Введение

PKirillW

22 окт. 2026 • 5 min read

Введение

Современная разработка сложных распределенных систем часто сталкивается с ограничениями классической модели CRUD. Когда требования к масштабируемости, производительности и точности данных растут, традиционные подходы могут приводить к проблемам синхронизации между операциями чтения и записи, а также к потере истории изменений объектов. Разработчикам необходимо находить способы эффективного разделения ответственности внутри системы для обеспечения её стабильной работы под высокой нагрузкой.

Именно здесь на помощь приходят паттерны CQRS (Command Query Responsibility Segregation) и Event Sourcing. Понимание этих концепций позволяет проектировать архитектуры, в которых данные не просто перезаписываются, а накапливаются в виде последовательности событий. Это дает уникальные возможности для аудита, восстановления состояния системы на любой момент времени и независимого масштабирования компонентов чтения и записи, что критически важно для высоконагруженных Enterprise-решений.

В данной статье мы разберем эти архитектурные подходы с практической точки зрения. Вы узнаете фундаментальные основы работы CQRS и Event Sourcing, погрузитесь в механизмы их внутреннего взаимодействия и изучите конкретные сценарии применения. Наша цель — дать вам четкое представление о том, как внедрять данные паттерны в реальные проекты для решения сложных бизнес-задач.

Основы

Для понимания архитектуры современных высоконагруженных систем необходимо четко разграничить два фундаментальных паттерна: Event Sourcing и CQRS. Несмотря на то что они часто применяются в связке, это разные концепции — одна описывает способ хранения данных, другая — модель взаимодействия с ними.

Event Sourcing (ES)

В классических приложениях мы сохраняем текущее состояние объекта (State-based storage). Если пользователь меняет адрес доставки, система выполняет UPDATE в базе данных. В Event Sourcing состояние не перезаписывается — вместо этого мы храним неизменяемую последовательность событий (Events), произошедших в системе.

Каждое событие является фактом прошлого, который невозможно изменить или удалить. Текущее состояние системы вычисляется путем «воспроизведения» этих событий от начальной точки:


{
  "event_id": "a1-b2",
  "type": "OrderCreated",
  "payload": { "order_id": 500, "status": "pending" },
  "timestamp": "2023-10-27T14:00:01Z"
}
{
  "event_id": "c3-d4",
  "type": "PaymentReceived",
  "payload": { "order_id": 500, "amount": 1500 },
  "timestamp": "2023-10-27T14:05:20Z"
}

Command Query Responsibility Segregation (CQRS)

CQRS — это принцип разделения операций чтения и записи на разные модели. В традиционных архитектурах мы часто используем одну и ту же структуру данных для выполнения запросов и изменения состояния, что создает узкие места при масштабировании.

Commands: Изменяют состояние системы (например, PlaceOrder). Они ориентированы на бизнес-логику, валидацию и атомарность записи.
Queries: Возвращают данные для интерфейса (например, GetOrderStatus). Они оптимизированы под скорость чтения, сложные фильтры и агрегации.

Контекст взаимодействия

CQRS идеально дополняет Event Sourcing в распределенных системах. Если ES является источником истины (Source of Truth), то CQRS предоставляет способы эффективно работать с этой истиной:

Команды записывают события в Event Store (хранилище событий).
Специальные обработчики — Projections — слушают поток событий и обновляют отдельные базы данных для чтения (например, Elasticsearch или Redis).
Запросы выполняются напрямую из этих оптимизированных представлений, не нагружая основной хранилище событий.

Как это работает

Переход от традиционной модели CRUD к связке CQRS (Command Query Responsibility Segregation) и Event Sourcing требует изменения фундаментального подхода к хранению данных: вместо сохранения текущего состояния системы мы начинаем сохранять последовательность событий, которые привели к этому состоянию.

Внутреннее устройство Event Sourcing

Основным компонентом здесь является Event Store — неизменяемый лог (append-only log), где каждое изменение записывается как отдельный факт. В отличие от реляционных таблиц, где операция UPDATE затирает старые данные, в Event Sourcing мы только добавляем новые записи.

Механизм работы строится на трех этапах:

Запись события: Когда пользователь совершает действие (например, оформляет заказ), система создает объект события.
Персистенция: Событие сохраняется в Event Store с уникальным идентификатором агрегата и временной меткой.
Восстановление состояния (Rehydration): Чтобы узнать текущее состояние объекта, система «проигрывает» все события этого агрегата последовательно.

Для оптимизации производительности при большом количестве событий используется механизм Snapshots — периодическое сохранение промежуточного состояния системы, чтобы не пересчитывать историю с самого начала.

Ключевые механизмы CQRS

CQRS разделяет операции чтения и записи на разные модели. Это позволяет независимо масштабировать и оптимизировать каждый из потоков:

Command Side (Пишущая сторона): Отвечает за бизнес-логику, валидацию и изменение состояния. Здесь данные структурированы для обеспечения целостности (например, нормализованные таблицы или объекты агрегатов).
Query Side (Читающая сторона): Предназначена исключительно для получения данных. Данные здесь могут быть денормализованы и оптимизированы под конкретные запросы UI или API (например, плоские таблицы в ElasticSearch или Redis).

Синхронизация через Проекции

Ключевым связующим звеном между двумя сторонами являются Проекторы. Как только новое событие попадает в Event Store, специальный обработчик (Projector) подписывается на него и обновляет соответствующую Read Model.

// Пример упрощенного проектора для обновления баланса
function handleOrderPaid(event) {
    const order = event.orderId;
    const amount = event.amount;

    // Обновляем денормализованную Read Model (например, в Redis или SQL)
    db.query(`
        UPDATE user_balances 
        SET current_balance = current_balance - ${amount} 
        WHERE user_id = ${event.userId}
    `);
}

// Обработка потока событий
eventStore.subscribe('OrderPaid', handleOrderPaid);

Важно понимать, что такая архитектура подразумевает согласованность в конечном счете (Eventual Consistency). Между моментом записи события и его появлением в Read Model может пройти небольшое количество миллисекунд.

Практическое применение

Переход от теоретического понимания CQRS (Command Query Responsibility Segregation) и Event Sourcing к их внедрению в продакшн требует четкого осознания границ применимости этих паттернов. Они не являются «серебряной пулей» для каждой задачи, но становятся незаменимыми в системах с высокой сложностью бизнес-логики, строгими требованиями к аудиту и необходимостью независимого масштабирования процессов чтения и записи.

Типовой сценарий: Система управления заказами (E-commerce)

Рассмотрим классический пример системы обработки заказов. Вместо того чтобы хранить только текущее состояние заказа в традиционной таблице Orders, мы сохраняем последовательность неизменяемых событий:

OrderCreated — заказ сформирован пользователем и находится в статусе «Ожидание».
PaymentReceived — оплата подтверждена внешним платежным шлюзом.
StockReserved — товары зарезервированы на складе для данного заказа.
Shipped — товар передан курьерской службе, статус обновлен до «В пути».

В такой архитектуре Command Side (сторона записи) отвечает исключительно за валидацию бизнес-правил и генерацию новых событий. Она гарантирует целостность данных внутри агрегата. Query Side (сторона чтения) потребляет эти события для построения различных проекций в зависимости от потребностей интерфейсов:

Elasticsearch — для быстрого полнотекстового поиска по всем заказам.
Redis — для отображения списка «активных» заказов пользователя на главном экране с минимальной задержкой.
PostgreSQL (Read Model) — для генерации сложных финансовых отчетов и аналитики.

// Пример упрощенного обработчика команды в системе заказов
async function handlePlaceOrder(command: PlaceOrderCommand): Promise {
  const order = OrderAggregate.load(command.orderId); // Загрузка агрегата из Event Store

  if (order.canBePlaced()) {
    // Создание события вместо прямого обновления поля в БД
    const event = new OrderCreated({ 
      userId: command.userId, 
      items: command.items,
      totalAmount: command.amount 
    });

    await eventStore.append(event); // Атомарная запись в Event Store
    publishToMessageBroker(event);  // Рассылка события для обновления проекций (Read Models)
  } else {
    throw new Error("Order cannot be placed: items out of stock or invalid user status");
  }
}

Лучшие практики внедрения

Чтобы избежать типичных архитектурных ловушек при реализации CQRS и Event Sourcing, следует придерживаться следующих принципов:

Идемпотентность команд: Каждый запрос от клиента должен содержать уникальный Correlation ID. Это гарантирует, что повторная отправка одной и той же команды (например, из-за сетевого сбоя или двойного клика пользователя) не приведет к дублированию действий в системе.
Снэпшоты (Snapshots): Для агрегатов с длинной историей событий необходимо сохранять промежуточные состояния («снимки»). Это позволяет избежать полной переборки всех событий при каждой загрузке сущности, существенно ускоряя работу системы.
Версионирование схем событий: События неизменяемы (immutable). Если структура данных в событии OrderCreated меняется, необходимо использовать стратегии обратной совместимости или поддерживать несколько версий обработчиков одновременно для старых записей.
Мониторинг задержки проекций (Projection Lag): В распределенных системах критически важно отслеживать время между записью события и его появлением в Read Model. Высокий лаг может привести к ситуации, когда пользователь выполняет действие, но не видит результат на экране из-за асинхронности обновления базы данных.

Заключение

Подводя итог, можно сказать, что сочетание паттернов CQRS и Event Sourcing является мощным инструментом для построения масштабируемых и отказоустойчивых систем. Мы рассмотрели фундаментальные основы этих подходов, механизмы работы с потоками событий и способы их интеграции в архитектуру приложения. Использование данных технологий позволяет не только обеспечить полную прослеживаемость изменений (audit trail), но и эффективно разделить нагрузки на чтение и запись, что критически важно для высоконагруженных проектов.

На практике рекомендуется внедрять CQRS и Event Sourcing постепенно: начинайте с тех модулей системы, где требуется сложная бизнес-логика или высокая интенсивность операций. Важно помнить о сложности обеспечения согласованности данных в распределенных средах и тщательно проектировать механизмы обработки событий перед масштабированием архитектуры на весь проект. Правильный выбор инструментов хранения событий и осознанный подход к моделированию доменов станут залогом успеха при переходе на эту современную архитектурную парадигму.