Event Sourcing без мифов: почему ваш микросервис не тянет на 'источник правды'

Ну давай разберем. Последние пару лет я наблюдаю, как джуны и мидлы с горящими глазами лепят Event Sourcing в каждый второй проект, даже не понимая, чем это отличается от простой записи в лог. На собеседованиях слышу: 'Мы сделали ES для аудита'. И тут же вопрос: а где у вас снапшоты? А как восстанавливаете состояние после падения? Тишина. Ребят, давайте честно: Event Sourcing — это не про аудит и не про 'крутость'. Это про то, что ваша бизнес-логика должна быть детерминированной, а каждый ивент — необратимым. Если вы храните события в PostgreSQL как JSON-строки и называете это ES, у меня для вас плохие новости. Вы просто делаете копию состояния в другой таблице. Давайте на примере. Представим, что у вас заказ в интернет-магазине. Классика: статусы 'новый', 'оплачен', 'отгружен'. При ES вы должны хранить не текущий статус, а последовательность ивентов: OrderCreated, PaymentReceived, ShipmentStarted. И вот тут начинается веселье. Как вы будете отвечать на запрос 'покажи заказы, которые оплачены, но не отгружены'? Без snapshot или материализованного представления вы утонете в переборе миллионов ивентов. И второй момент: консистентность. Если у вас несколько агрегатов, которые общаются через события, вы автоматически получаете eventual consistency. И это нормально для многих сценариев, но не для всех. Например, проверка лимитов на счете клиента: если вы ждете, пока ивент дойдет до другого сервиса, а потом еще и обработается, то у пользователя может уйти два платежа. И что, 'извините, у нас сага'? Сага — это не магия, это компенсирующие транзакции, которые часто сложнее, чем сам ES. Мой опыт: ES оправдан в системах с высокими требованиями к аудиту и сложной бизнес-логикой, где каждое изменение должно быть воспроизводимо. Например, в финансах или логистике. Но если у вас туду-лист или бложик, то вы просто усложняете себе жизнь. Бенчмарки показывают, что даже с CQRS и EventStore средняя задержка на запрос снапшота растет линейно при отсутствии нормальной стратегии снэпшотов. Короче, прежде чем пилить очередной ES на MongoDB, подумайте: а не проще ли сделать нормальную историю изменений через триггеры или отдельную таблицу? Иногда грабли лежат прямо под ногами, а вы их зачем-то красите в золото.