+1 есть опыт таких граблей, где ES затащил ради попробовать как карго, в первый год работы в индустрии))
Типа ну круто же, без осознания зачем оно тут и что под него готовой инфры мало, что полезут приколы распределенных систем с порядком сообщений, версионированием ивентов, апдейтерами или как оно там
Было интересно, но заполнил надолго ибо ещё и больно ударила ручка граблей по лбу :)
Создал себе технической сложности, там где хватило бы таблички с логом событий рядом с основной таблицей

Тот стартап умер, поэтому ошибка похоронена с ним
В проде успело пожить с полгода и сносно работало😁
Только нагрузка была 10-30 заказов в день у доставки, а закладывали как на деливериклаб

Там ещё CQRS был до кучи и разные бд под рид модели и ивенты, чтобы как у взрослых - и отсюда полез accidental complexity

примерно последние 10 лет я занят только системами с ES
и есть очень много кейсов в многих индустриях, которые на ES хорошо ложатся

построить систему на ES (разделение на "здесь и сейчас" состояние aggregate root) и downstream из которого строится read model  - это, разумеется,  дороже, чем сделать традиционно-реляционную базу с CRUD
но зато 1) в системе принципиально нет локов, оно масштабируется на порядки чисто опс средствами, то есть без переписывания кода вообще и 2) к основному состоянию системы можно дописывать любые агрегаторы

если нет задачи масштабирования и расширения агрегаторов - без ES дешевле

1) Если локи нужны в бизнес-логике (а они там обычно нужны), то их реализация в ES не простая.
2) Аггрегаты можно дописывать только если хранить весь поток событий вечно (и все их апдейтеры), а это очень противно.
Реально нужно схлопывать события или переносить, а при большом объеме это тоже не просто
3) С масштабированием там тоже есть проблемы, но другие )
4) И гораздо сложнее удерживать систему в целостном состоянии. Монорепа, впрочем, чуть упрощает жизнь. Но не в едином стеке делать ES вообще страшно.

Ну и масштабирование можно делать и не через ES, как и расширение агрегатов )

1) не, ящетаю локи вообще не нужны, можно _всё_ делать без них, это просто сложнее (но зато масштабируется)
2) у журнала хранят обычно "горячий хвост" + всё остальное в data lake
вообще агрегаторы бывают разные - бывают которым нужно только последнее состояние (и они поэтому быстро восстанавливаются из снапшота), а есть stateful которые читают только события и хранят своё собственное состояние
3) да, проблемы есть, куда без них, но принципиально (где данные хранятся, как обрабатываются, куда клиенты коннектятся) ничего не меняется
4) ну, это вообще не ES-специфично, и да, монорепы это economy of scope, плюс репа == плюс косты

У меня была проблема обеспечить уникальность чего-то для агрегатов, на Райт модели
В итоге советовали хак типа пиши рядом в реляционную бд которая умеет гарантировать уникальность и лови исключение
Подробно не помню уже
База под ивенты была eventstore

так это ж святой грааль эвент сорсинга, гарантировать что сущность с данным id уникальна в кластере

1) Ну, оно иногда сильно сложно. Тот же финтех через блокировки делать проще )
4) Для классического обмена через REST/gRPC у любого сервиса есть очевидный контракт.
А вот методов простого описания контракта сервиса для ES - нормальных нет.

И как решается?

так ES не должен наружу торчать как сервис, что мешает к нему делать интерфейс, хоть бы и REST
изменения POST, чтение (из рид модели) GET

из известных мне в это умеют Kafka (streams) и Akka

Я про внутренние контракты, между сервисами в одном контексте.

Ну, kafka streams - это уже монстр (и с базой внутри).
A Akka тут при чем? Это же просто акторный движок без гарантий

Kafka Streams мне тоже не нравится, там какой-то бангалорский говнокод внутри
а Akka это акторный движок с кластерным шардингом

мм, то есть просто интерфейсы классов? ну там то же самое, команды и чтения из рид модели?

Угу, но у акки нет ни гарантий доставки, ни гарантий персистанса. Да и известный мне персистанс медленный очень.
Проще написать свое поверх субд.

В общем это последствия того что на синиоров и архитектора у стартапа деньги кончились, их уволили, остались вчерашние студенты
Джун в лице меня затащил ивентсорсинг потому что слышал что это модно и никто не остановил с криками ты что творишь у нас нагрузка полтора землекопа, а стартап умрет на неделе😁
Но зато получился интересный опыт)

При чем тут классы? У тебя есть контекст, в нем пачка сервисов, у сервисов есть внешние контракты, которые стандартным образом описываются из кода.
Для gRPC/Rest есть куча простых механизмов описания контракта и его проверки.
А вот для ES уже простых методов "кто какие события получает и отправляет" уже нет.
Про описание семантики связи событий (самое важное), то вообще все грустно.

Как посмотрю на сагу с хореографией - то ужас берет