мы на не очень большом объеме событийных данных сейчас тоже живем в pg

основная причина по которой не взяли кафку сразу - по пг есть ощутимая экспертиза в компании

А пишите, пожалуйста, ваши объёмы? "Очень большой" - это сколько в сутки? У нас вот 9.5 миллиардов. Мне кажется, PG треснет. Храним в кластере Кликхауса.

эм. _не_ очень большой же

9.5 миллиардов просто событий или событий, реализующих полноценный ES?

Пардон, не увидел. И нет, я про чисто аналитические события.

у нас порядок десятков миллионов, постгрес это в обе стороны крутит суперлегко без каких-то усилий

Спасибо, Игорь, выбор стал понятнее
Вот здесь неплохо описаны боли, ждущие с ES
https://chriskiehl.com/article/event-sourcing-is-hard
Что почувствовал на себе из того что вспомнил:
- нет готовой инфраструктуры - реплей стрима для воссоздания агрегата, десериализация событий - писать самому
- создание новой проекции - надо делать аудит лог, и проигрывать его в проекцию
- eventual consistency lag в consumer, если нужно что-то прочитать из проекции
- вследствие eventual consistency/CQRS на разных базах - события приходят не по очереди/с дубликатами
- транспорт потерял событие N, событие N+1 пришло - цепочка N, N+1 не собралась, проекция зависла в ожидании N - не заложил повторную отправку. Возможно причины были в работах по переезду на другой сервер, что-то очень неудачно наложилось - но потерянное сообщение факт
До каких болей не дошел, но они очевидны на горизонте больше года
- версионирование событий (апдейтеры)
- большое количество событий в стриме (снэпшоты)
- а что если мы спроектировали события неправильно?

Второй раз в ES бы ввязался, очень основательно подумав надо ли оно и потянет ли команда
Тогда пилил в одно лицо

про боли, решения:
- апкастинг эвентов как одна из стратегий версионирования
- снепшоты, да
- апкастинг с демультиплексированием

по последнему пункту - если доменная область была хоть немного проработана, то _совсем_ неправильно сделать не очень просто, а большая часть "тут неплохо бы несколько событий вместо одного" или наоборот "тут было достаточно одного, зачем-то сгребли в кучу" относительно ок решается преобразованиями при чтении

про "основательно подумать" и требования к команде абсолютно согласен, выбор несколько упрощается, когда реализовываешь что-то предельно событийное в своей природе (самый примитивный пример - бухгалтерские книги как литералли "ES на бумаге")

Спасибо! Бухгалтерия наверное один из любимых демо-примеров в объяснении ES в статьях
А с потерей событий, и созданием новых проекций - какие у вас решения?
Для первого очевидно - не терять, at least once delivery, восстановление в ручном порядке если что-то сильно пошло не так? В аудит логе событие было, до проекции не дошло.
Были ещё мысли о circuit breaker - но не понятно, каковы дальнейшие действия в автоматическом режиме, если потеряно одно из событий

с проекциям осознанно суперпримитивно, мы их обновляем синхронно

да, это не by the book (но на самом деле нет, жесткого требования нигде нет), но снимает огромный слой сложности в реализации и синхронизационных проблем

но конкретно в нашем случае это работает только потому что мы не ожидаем огромного множества событий для одного агрегата в очень небольшой промежуток времени

(в кредитных линиях самая нагруженная часть - обслуживание, и она нагруженная _в общем_, у конкретного же займа чудом может набраться сотня событий за сутки)

https://vectorized.io/ - redpanda замена кафке с 100% api compatibility

Я пришел к неплохой в общем-то альтернативе там где полноценный ES не нужен
Current state в таблице + таблица лог событий, в которую просто пишем события в дополнение к изменению current state

Если нужно завязать логику на последовательность действий или из нее что-то ещё выводить - для простых доменов подойдёт

Раньше был тренд на то, что в компании приходили эвангелисты скрама и рассказывали про новое светлое будущее, которое скоро наступит. Сейчас же ходят по компаниям и рассказывают про Event Storming

...но пришел вирус и их выперли сразу после маркетологов...