Проекции, replay и снапшоты

Проекции: read models из журнала событий

Журнал событий — источник истины для write-стороны. Он не предназначен для паттернов доступа при чтении. Отвечать на запрос «все просроченные заказы аккаунт-менеджера Чена» сканированием и свёрткой 200 000-записного журнала при каждой загрузке страницы — структурно неправильно.

Projection — процесс, читающий события из журнала и строящий денормализованную read model, сформированную для конкретного запроса. Концепция та же, что в CQRS (юнит 07) — ключевое отличие в том, что источником проецирования является журнал событий, а не нормализованная реляционная таблица.

Каждая projection подписывается на поток событий и обрабатывает каждый интересующий тип:

on OrderPlaced:          вставить строку в OrderDashboard со status "pending"
on OrderApproved:        обновить строку, установить status "approved", approved_by, approved_at
on InvoiceGenerated:     обновить строку, установить status "invoiced", invoice_id

Результат — таблица OrderDashboard с одной строкой на заказ, денормализованной и сформированной для запроса дашборда. Запросы обращаются напрямую к read model — без свёртки событий во время запроса.

Rebuild by replay: структурная суперсила

Поскольку журнал событий — источник истины, а read model — производный артефакт, read model можно перестроить с нуля в любое время, воспроизводя полный журнал событий через функцию projection. Это структурно отличается от CRUD-системы, где read model и write model — одни и те же данные, и «воспроизводить» нечего.

Rebuild-by-replay ценен в нескольких сценариях:

Изменение схемы: Дашборду нужен новый столбец days_to_first_payment. Добавить столбец в таблицу read model, обновить логику projection для его вычисления, затем воспроизвести все события. Каждая историческая строка получает корректное значение, вычисленное из исходных данных события. Никакой write-side миграции.

Исправление бага: В projection был баг — она неправильно вычисляла признак просрочки, помечая заказы просроченными на два дня раньше. Исправить логику projection, воспроизвести журнал, и read model теперь корректна для всех исторических данных.

Новая read model: Финансовой команде нужен новый view: все заказы, сгруппированные по расчётному периоду. Создать новую projection, строящую таблицу BillingPeriodSummary. Воспроизвести существующий журнал событий для построения из истории. Не нужно ждать накопления будущих событий.

Снапшоты: ограничение стоимости replay

Загрузка агрегата свёрткой его полного журнала событий становится дорогой по мере роста журнала. Заказ с 4000 событий требует 4000 вызовов applyEvent, прежде чем команда вообще начнёт обрабатываться. Это проблема производительности свёртки из урока 1.

Снапшот — кешированный промежуточный результат свёртки. На каком-то порядковом номере N приложение сохраняет производное состояние агрегата как снапшот рядом с журналом событий:

{
  aggregate_id: "order-48291",
  snapshot_seq: 3800,
  state: { status: "invoiced", total: 48200, line_items: [...], ... },
  created_at: "2024-06-01T12:00"
}

При следующей загрузке вместо начала с события 1 и применения всех 4000 событий приложение:

1. Загружает последний снапшот (состояние на seq 3800)
2. Загружает только события после seq 3800 (события 3801–4000)
3. Сворачивает только эти 200 событий поверх состояния снапшота

Стоимость свёртки падает с 4000 до 200 шагов. По мере добавления новых событий новый снапшот берётся периодически.

Критический инвариант: снапшот — не источник истины. Источник истины — журнал событий. Снапшот можно удалить в любое время — состояние агрегата всегда можно восстановить свёрткой полного журнала с события 1. Снапшоты существуют исключительно для производительности свёртки; они не заменяют события.

Временны́е запросы: replay префикса журнала

Урок 1 ввёл временно́й запрос: чтобы получить состояние заказа №48291 третьего марта в 14:00, отфильтровать журнал до временно́й метки и свернуть префикс. Это структурное следствие неизменяемого append-only журнала.

Временны́е запросы влекут следствие для производительности: они не могут использовать снапшот, взятый после целевой временно́й метки (этот снапшот включает события, которые нужно исключить). Нужно складывать с начала журнала до целевой временно́й метки. Для агрегатов с очень длинной историей временны́е запросы к старым временны́м меткам дороги. Это известная структурная стоимость event sourcing — управляема для разовых комплаенс-запросов, но не должна быть на горячем пути real-time запросов.

Версионирование событий и upcasting

Журнал событий неизменяем — уже хранящиеся события нельзя изменить. Но понимание приложением того, что означает событие, эволюционирует. Через шесть месяцев после запуска системы OrderApproved получает новое поле approval_threshold. В журнале есть 40 000 событий OrderApproved, записанных до этого поля. Когда projection воспроизводит их, она встречает события без нового поля.

Два структурных ответа:

Weak schema / tolerant reader: Projection обрабатывает OrderApproved с политикой толерантности: если approval_threshold отсутствует, считать его null или значением по умолчанию. Код projection обрабатывает как старую, так и новую версии события. Работает для аддитивных изменений (новые необязательные поля) и является самым простым подходом.

Upcasting: При загрузке (или во время чтения) старые версии событий преобразуются в текущий формат до передачи в функцию applyEvent агрегата. Функция upcast для v1 → v2 OrderApproved может устанавливать approval_threshold: null для всех v1 событий. Логика свёртки агрегата видит только текущий формат. Журнал событий сохраняет исходные байты v1 — upcasting применяется при чтении, а не записывается обратно в журнал.