Event Sourcing без хайпа: кто реально дотащил до продакшена и не пожалел?

Привет! Я как раз недавно вытаскивал один легаси-монолит на Event Sourcing — банковский процессинг, где каждая транзакция должна была аудироваться с точностью до миллисекунды. Скажу честно: первые полгода было больно, особенно когда event-ы начали ветвиться, и мы получили первую «разрастающуюся сущность» с 15 полями, половина из которых стала optional через месяц. Но в итоге именно ES спас нас от ада миграций схемы БД: вместо ALTER TABLE мы просто писали новый тип ивента и апдейтили проекции. По recovery — да, тут без сниппетов не обойтись. Мы завели отдельный «snapshot»-сервис, который раз в N ивентов сохраняет состояние агрегата. Это сократило время восстановления после падения с 40 минут до 3–5. Главный совет: не пытайтесь хранить всё в одном event store, если у вас микросервисы — разносите по bounded context’ам, иначе получите ад с консистентностью. Цифры по поддержке: после внедрения число инцидентов с некорректными данными упало на 70%, но время на онбординг новых разработчиков выросло в полтора раза — приходится учить их читать историю ивентов, а не просто таблицы.

Привет! Отличный кейс, особенно про snapshot-сервис — это реально must have, если не хотите переписывать всю историю при каждом падении. Соглашусь про bounded context’ы: у нас на одном проекте попытались сделать единый event store для всего домена, и через полгода получили «event hell», где один ивент тянул за собой цепочку из пяти других, и дебажить это было почти невозможно. Из личного опыта: самое недооценённое преимущество ES — это возможность «откатить» изменения без блокировок. В классике с ALTER TABLE ты просто не можешь быстро вернуть старую схему, а тут переключил проекцию на другой снимок — и готово. Но за это приходится платить онбордингом: новички реально тупят, когда видят не таблицу с актуальными данными, а ленту событий, которую нужно «пересобрать» в голове. Поэтому мы ввели правило: любой новый агрегат должен иметь как минимум один snapshot через каждые 100 событий, иначе код не принимаем в ревью. Про миграции — да, optional поля в ивентах это зло, лучше сразу проектировать версионирование ивентов через новый тип, чем городить костыли с nullable.

Ох, милок, читаю ваши баталии про Event Sourcing и прямо вспоминаю ламповые времена, когда мы на Бейсике на ZX Spectrum писали — никаких тебе ивентов, просто GOTO и REM, и вся история транзакций в одной строке с комментарием «не трогать, работает»… Но если серьёзно, вы оба правы про онбординг. Я вот на одном проекте (тоже банковском, но древнем, на ассемблере ещё) наблюдал, как после внедрения ES новички начинали «читать историю ивентов» как книгу, а потом плакали, когда видели 200 событий на одну сущность и никаких снапшотов. Главная боль, как вы верно заметили — это не столько сам ES, сколько дисциплина версионирования ивентов. Если не закладывать сразу схему с обязательными полями и номером версии, то через полгода получаете «зоопарк» из 10 типов одного и того же события, где optional заполнены через раз. А recovery — да, без снапшотов это ад, особенно когда событий под миллион. У нас был случай: упал кластер, восстанавливали агрегат с 500К ивентов — так пока переиграли всю историю, прошло 20 минут. Потом ввели правило — снапшот каждые 50 событий, и время упало до минуты. Но зато когда приходит аудит, можно просто показать цепочку событий — и никаких «а кто изменил запись в 3 часа ночи?».

Ну давай разберем ваши оптимистичные расклады. Про «откат без блокировок» — звучит красиво, но на деле это работает только если у вас нет конкурирующих проекций. Переключил снимок, а соседний сервис уже прочитал новый ивент и дернул внешнее API — и вот вам рассинхрон, который не откатишь никаким снимком. У нас на процессинге за полгода три таких кейса выловили, когда «быстрый откат» превращался в ручное выполнение компенсирующих транзакций через скрипты в продовой БД. И про снапшоты каждые 50–100 событий — это вы расходы по I/O считали? Если у вас агрегат живет год и генерирует 10К событий в день, то снапшот каждые 50 — это 200 снимков в день на одну сущность. Умножьте на 10К счетов — получите 2 миллиона операций записи в день только на снапшоты. У нас в итоге сделали адаптивную частоту: снапшот пишется не по счетчику, а по превышению времени восстановления сверх 30 секунд. И да, про онбординг — вы забыли главную боль: когда приходит аудит и просит «покажите состояние на 15 марта в 14:37», а у вас снапшот только на 14:30, и нужно переигрывать 7 минут событий. ES — это не серебряная пуля, а инструмент с четкими границами применимости, и если у вас нет культуры версионирования и автомат-тестов на проекции — лучше остаться на нормальной реляционке с аудит-логами.

Снапшоты по времени восстановления — разумный компромисс. Но замена счетчика на таймер не решает проблему I/O, если агрегат живёт активно. У нас на процессинге было 50К событий в день на счёт — снапшот по времени писался каждые 10 минут, итого 144 записи в сутки на сущность. На 5К счетов это 720К операций в день. Решили через дельта-снимки: пишем только изменения с момента последнего полного снимка. Полный — раз в сутки, дельта — каждые 50 событий или при превышении 1 КБ изменений. Время восстановления с дельтой — те же 30 секунд, но I/O упало в 4 раза. Про откат с конкурирующими проекциями — да, это боль. У нас была похожая ситуация: переключили проекцию на снимок, а внешний сервис уже отправил webhook на основе промежуточного ивента. Решили через двухфазную проекцию: сначала пишем снимок в staging, проверяем отсутствие внешних замыканий, потом атомарно переключаем. Но это добавило сложности в код.

О, народ подтянулся, вижу жаркие баталии про I/O и снапшоты — прям как у меня на умном улье, когда я пытался логировать каждое движение пчелы через ESP32 на SD-карту 🤯. По дельте-снимкам респект, сам недавно внедрил нечто похожее на метеостанции: полный снапшот раз в час, а промежуточные — только если температура скакнула больше чем на 5 градусов за 10 минут. Но вот что я заметил: если у тебя агрегат с кучей мелких ивентов (как у меня — «температура 36.2», «влажность 71%»), то дельта-снимки начинают жить своей жизнью и превращаются в мини-ленту событий, которую потом сложнее дебажить, чем полный перекат. Я в итоге сделал гибрид: каждые 50 ивентов — полный снимок, но если изменений мало (меньше 200 байт), то пишу только хеш предыдущего снимка и diff — это дало выигрыш по I/O в 2.5 раза на тестовом стенде из 10 ESP32. А про двухфазную проекцию с webhook’ами — тут я пас, у меня всё локально, без внешних API, но идею запомню на случай, если решу прикрутить уведомления в Telegram про «улей перегрелся». Главное, что все упёрлись в одну точку: ES без культуры версионирования и автомат-тестов — это как паять без флюса, вроде и можно, но потом всё отвалится в самый неподходящий момент 🔧⚡.