event sourcing

Event Sourcing — это паттерн хранения данных, при котором состояние системы определяется не текущими значениями в базе данных, а полной последовательностью событий, которые к этому состоянию привели. Вместо хранения строки «Баланс счёта: 5000 руб.» система хранит события: «Пополнение на 10 000», «Снятие 3 000», «Начисление процентов 200», «Комиссия 200». Текущее состояние вычисляется воспроизведением этой последовательности.

Принцип работы Event Sourcing

Операции над агрегатом (бизнес-объектом) не обновляют его данные напрямую. Вместо этого генерируется неизменяемое событие, описывающее произошедшее: OrderPlaced, PaymentReceived, OrderShipped. Событие записывается в event store — постоянное append-only хранилище.

При необходимости получить текущее состояние агрегата система загружает все его события из store и «проигрывает» их по порядку, применяя к начальному состоянию. Это называется replay или reconstitution.

Event Store: ключевой компонент

Event store — специализированная или общая база данных, оптимизированная для последовательной записи событий. Ключевые свойства: события только добавляются (никакого UPDATE или DELETE), строгая упорядоченность в рамках агрегата, хранение метаданных (timestamp, correlation ID, кто создал).

Специализированные: EventStoreDB (Greg Young). Универсальные: PostgreSQL (таблица событий), Kafka (как долгосрочный лог), DynamoDB с условной записью.

Снапшоты для оптимизации

Если агрегат накопил тысячи событий, каждый replay становится дорогим. Решение — снапшоты: периодически сохраняется текущее состояние агрегата. При следующем запросе загружается снапшот и только события, произошедшие после него. Снапшот не заменяет события — они сохраняются навсегда для полного воспроизведения.

Проекции и Read Models

Для эффективного чтения Event Sourcing используют проекции — асинхронные подписчики на поток событий, строящие денормализованные read-модели. Проекция получает событие OrderPlaced и обновляет таблицу заказов для отображения в UI. Проекцию можно удалить и пересоздать с нуля, проиграв все события — это даёт возможность ретроспективно добавлять новые запросы к историческим данным.

Преимущества Event Sourcing

• Полный аудит: история изменений сохраняется навсегда. Каждое изменение — кто, когда, почему. Ценно для финансовых, медицинских систем, любого бизнеса с требованиями к аудиту.
• Temporal queries: состояние системы на любой момент в прошлом вычисляется воспроизведением событий до этой точки.
• Отладка и диагностика: точное воспроизведение последовательности событий, приведших к ошибке.
• Гибкость проекций: новые read-модели добавляются без изменения исходных данных.
• Интеграция: события публикуются в брокер, другие системы реагируют асинхронно.

Сложности Event Sourcing

Эволюция схемы событий. Если изменить структуру события, старые события не соответствуют новой схеме. Решение — версионирование событий и upcasting (трансформация старого события в новый формат при загрузке).

Eventual consistency. Проекции обновляются асинхронно. Пользователь создаёт заказ и не сразу видит его в списке.

Сложность запросов. Произвольные запросы к событиям неэффективны. Нужны проекции для каждого типа запроса.

Операционная сложность. Дополнительная инфраструктура, управление версиями событий, пересоздание проекций.

Когда применять Event Sourcing

Event Sourcing оправдан при: требованиях к полному аудиту истории (финансы, здравоохранение), необходимости temporal queries, сложных доменах с богатой историей изменений, системах, где события — первичная сущность (торговые платформы, игры, IoT).

Event Sourcing избыточен для простых CRUD-систем, где история изменений не нужна. Начните без него, добавьте при появлении реальной потребности.