Event sourcing: почему хранение истории меняет вопросы к аналитике
Что такое event sourcing как подход к данным и почему это решение с долгосрочными последствиями для аналитических возможностей компании.
Большинство систем хранят текущее состояние. Заказ изменился - старое значение перезаписано. Статус обновлён - предыдущий потерян. Баланс пересчитан - история движений остаётся только в том виде, в каком кто-то догадался её предусмотреть.
Это привычная модель. Она работает для операций. Но она сильно ограничивает то, о чём вы сможете спросить свои данные через два года.
Что такое event sourcing
Event sourcing - это подход, при котором система хранит не текущее состояние объекта, а последовательность событий, которые к этому состоянию привели. Текущее состояние при необходимости вычисляется из событий.
Практический пример: вместо того чтобы хранить "заказ в статусе 'доставлен'", система хранит "заказ создан → оплачен → передан в доставку → доставлен". Текущий статус - это результат воспроизведения этой цепочки.
Это не новая идея. Бухгалтерия работает именно так столетиями: не перезаписывают баланс, а записывают каждую транзакцию, а баланс выводят из истории. Банковские системы устроены так же. Модель журнала важна не только внутри одной системы, но и для взаимодействия систем между собой: лог событий как источник истины побеждает точечные интеграции по тем же причинам.
Что это даёт аналитически
Когда история событий сохранена, появляются вопросы, которые при хранении только текущего состояния просто не задать.
Как изменялось поведение клиента с течением времени? Какой путь прошёл заказ до отмены? В какой момент процесса чаще всего возникают задержки? Как выглядел ассортимент год назад в аналогичный период?
Всё это требует истории. Если история есть - вопросы задаются. Если нет - аналитик смотрит на актуальные данные и строит предположения о том, что было раньше.
Кроме того, event sourcing даёт возможность "перемотать" состояние на любой момент в прошлом. Это ценно для аудита, расследования инцидентов и отладки. Понять, откуда взялась цифра в отчёте и кто несёт ответственность за цепочку решений, которая её породила, становится возможным, когда история сохранена как события.
Где это создаёт сложности
Event sourcing - это архитектурное решение с последствиями, и его не стоит применять везде.
Объём данных растёт быстрее, чем при хранении только текущего состояния. Нужны механизмы снапшотов, чтобы не воспроизводить тысячи событий каждый раз при чтении.
Запросы вида "найти все заказы в статусе X прямо сейчас" требуют отдельного read-слоя - проекций, которые хранят текущее состояние, построенное из событий.
Схема событий должна быть стабильной - изменить прошлое нельзя, можно только добавить корректирующее событие. Это требует дисциплины в проектировании.
Когда имеет смысл думать об этом
Event sourcing оправдан, когда:
- история изменений имеет самостоятельную ценность для бизнеса - для аудита, аналитики или регуляторных требований;
- нужна возможность восстановить состояние системы на любой момент в прошлом;
- процессы достаточно сложные и важно понимать, как конкретный результат был достигнут.
Для простых справочников, конфигурационных данных и всего, что не имеет значимой истории - традиционное хранение состояния проще и достаточно.
Ключевой вопрос для руководителя: какие решения мы принимаем на основе данных, и нужна ли нам для этого история, или достаточно текущего снимка? Ответ на этот вопрос определяет, стоит ли вкладываться в хранение событий.