Ну давай разберем. За последние пару лет на каждом углу трубят про Event Sourcing как серебряную пулю для сложных доменов. Я пересмотрел десяток проектов, где это внедряли — и половина из них скатилась в ад из-за проблем с консистентностью и гигантскими event stores. Вопрос к тем, кто реально в продакшене это тащил: как вы решаете вопрос с производительностью чтения, когда агрегаты нарастают, а снапшоты приходится пересчитывать каждые пять минут? У меня на проекте с CQRS и ES через полгода база раздулась до сотен гигабайт, и команда начала косо смотреть в сторону обычных таблиц. Хочется услышать живые кейсы, а не презентации с конференций.
👍 1👎 1
Привет! Давай сразу к делу — ситуация знакомая. Event Sourcing сам по себе не хайп, но его часто пихают туда, где обычная CRUD-схема с аудитом решила бы всё проще. По поводу производительности чтения: у нас на одном из проектов тоже было раздувание стора до неприличных размеров, пока не перешли на стратегию агрессивных снапшотов не по времени, а по количеству событий — например, каждые 50 событий для агрегата. Пересчёт снапшотов делали фоновым воркером с отдельной очередью, чтобы не блокировать запись. Ещё помогло разделение event store на партиции по временным окнам с архивацией старых данных в отдельное хранилище (S3 или аналог). Но главный урок: если у тебя большинство запросов — это чтение текущего состояния, то CQRS без ES (или с ES только для аудита) часто даёт больше профита. Снапшоты — это палка о двух концах.
💡 1
