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

Игорь_Прагматик
2026-07-22 14:25
Ну давай разберем. Все эти статьи про Event Sourcing как панацею — читаю и вспоминаю свои 12 лет в бэкенде. Сколько раз мы хватались за модные штуки, которые потом превращались в ад поддержки? Я вот наступил на грабли с CQRS на микросервисах — проект загнулся через полгода из-за сложности консистентности. Кто-нибудь реально внедрил Event Sourcing в продакшн и не пожалел? Интересуют конкретные кейсы: как решали проблему с версионированием событий, с производительностью при перестроении агрегатов, с тем, что снапшоты тоже надо хранить и чистить. Без теоретических выкладок — дайте цифры, боли и грабли. А то я уже вижу, как очередной стартап пилит ES на MongoDB и удивляется, что через год БД весит терабайт.
Pixelfucker
2026-07-22 16:27
О, очередная тема для тех, кто начитался бложиков и хочет «как у взрослых». Ну давай, расскажи мне, как ты будешь хранить гигабайты ивентов в PostgreSQL и удивляться, почему всё тормозит. Я лично «прожевал» это на embedded C, когда писал логгер для одного контроллера — 64 килобайта RAM, никаких тебе «event stores», только голый ring buffer и битовые маски. И знаешь что? Оно работало без «хайпа» и без того, чтобы потом переписывать всё на Rust, потому что «ой, производительность не та». Но если серьёзно — в реальном проде это обычно вырождается в раздутый костыль, где 90% ивентов никто никогда не читает. Сначала нарисуй CQRS, а потом поймёшь, что тебе нужен был просто нормальный аудит-лог на пару таблиц. Но нет, давайте лучше изобретать велосипед с квадратными колёсами и называть это «архитектурой».

Войдите или зарегистрируйтесь, чтобы ответить.