Ну давай разберем. На очередной конфе очередной спикер с горящими глазами вешает лапшу про Event Sourcing как серебряную пулю для аудита и историчности данных. В теории — сказка, на практике — геморрой с консистентностью, версионированием схем и диким разрастанием стора. Кто-то тут реально выкатил это в прод на высоконагруженном проекте, а не просто на пет-проджекте с тремя ивентами в день? Интересно послушать про грабли с производительностью снапшотов и то, как вы выкручивались из ситуации, когда модель домена поменялась, а в сторе уже лежит сотня тысяч ивентов старой версии.
Я сам пару лет назад попробовал прикрутить CQRS с Event Sourcing на одном внутреннем сервисе для логов транзакций. Через полгода понял, что компенсация за гибкость — это адское усложнение дебага и необходимость тащить целую инфраструктуру для перестроения агрегатов. В итоге откатились обратно на CRUD с обычной аудит-таблицей — и жить стало проще. Так что вопрос: оно вообще стоит свеч для 95% задач или это очередной хайп, который сожрет бюджет, а выхлопа не даст?
Снапшоты и версионирование — это да, боль. Но проблема часто не в ES, а в том, что его пихают туда, где нужен обычный аудит-трейл. Высоконагруженный проект с ES — это не про логи транзакций, а про ядро, где каждое изменение критично и воспроизводимо. У нас на одном сервисе бронирований снапшоты ребилилдились раз в 500 ивентов — дешево и сердито. Модель меняли через апкаст-миграции: старые ивенты не трогали, а снапшот писали уже в новой схеме. Дебаг, кстати, стал проще, когда добавили replay на тестовом стенде — баги ловились до прома.
Про откат на CRUD с аудит-таблицей — это нормально. Для 95% задач ES избыточен. Но говорить, что он не стоит свеч для остальных 5% — значит игнорировать разницу между хайпом и инструментом под конкретную боль. Если аудит не нужен на уровне каждого click'a и не требуется восстанавливать состояние на любой момент времени, то да, CRUD проще. Но когда это нужно — CRUD превращается в костыль с триггерами и CDC.
👍 1👎 1
Слушай, я в целом согласен с посылом, но добавлю ложку дегтя. Твой пример с бронированиями — это как раз тот редкий случай, когда ES оправдан, потому что там каждый ивент — это деньги и SLA. Но проблема в том, что 90% команд, которые пытаются затащить ES, видят эту историю с бронированиями и думают: «О, у нас тоже есть заказы, давай!» — а по факту у них обычный каталог с тремя статусами. И вот тут начинается то самое «накидали говна на вентилятор».
Про миграции через апкасты ты правильно сказал, но это работает только если у тебя схема ивентов не меняется кардинально. Когда в продакшене лежат ивенты с полем `user_id: int`, а ты переезжаешь на `user_uuid: string` — начинается цирк с конвертацией на лету и двойными версиями снапшотов. Я видел проект, где для этого написали отдельный сервис-трансформер, который жрал память террабайтами, потому что старые ивенты нельзя было просто взять и перезаписать. В итоге проще было поднять новый инстанс с чистой историей и забить на «историчность с самого начала».
Так что да, для 95% задач это хайп, который сожрет бюджет на инфраструктуру, обучение команды и поддержку легаси. А для оставшихся 5% — это must have, но только если у тебя есть выделенная команда, которая будет это администрировать, а не джун, который вчера прочитал Мартина Фаулера.
О, ну да, классика — начитались Фаулера и давай пилить ES на кошельке для пополнения баланса в мобильной игре. Согласен, 90% таких проектов заканчиваются тем, что ивенты летят в PostgreSQL без партиционирования, снапшоты пересчитываются по крону раз в час, а при первом сбое консистентности все дружно проклинают день, когда решили «поиграть в архитектуру».
Проблема с трансформерами, кстати, решаема, если изначально думать головой и не хранить сырые JSON-блобы, а сразу закладывать Avro или Protobuf со схемами. Но кто ж будет слушать, когда можно накидать говна на вентилятор, а потом героически это разгребать? В итоге ES реально вывозит только там, где аудит и откаты — это не опция, а закон. Всё остальное — оверхед ради красивого слова в резюме.
