Ну и чо?

Пиарить свою базу данных

Я мало пока смыслю в кафке, но уже например без optimistic lock я не понимаю как сделать eventstore

Да не нужны локи

А как обеспечить консистетность агрегата?

В смысле?

В кафку продюсер пишет в тот же пртишен из которого читает консьюмер

Ну мы будет делать какие-то бизнес операции опираясь на старый стейт. И вот race condition

Вообщем если не рассматривать kafka как ES event store, а только как брокера, то вариант с сохранением offset а основной базе норм?

Не совсем корректно мыслите, коллега. Kafka streams смотрел?

Да, я понимаю, там типа exactly_once в рамках кафки, прочитал - обработал - записал

Вот и все

Кафка будет хранить результаты агрегата в другом топике. Если народ всегда можно пересчитать из исходного топика

Короче можно сделать и все будет ок

https://www.confluent.io/blog/tag/event-sourcing/ рекомендую полазить тут. А я ушел в качалку

Мб потом ответите)

Я приведу пример с optimistic lock.
Классический пример списание денег.
Подписчику приходит событие из кафки КулпенТовар(IDТовара, Сумма). Допустим мы берем проекцию аграгата/стрима/актора баланса клиента из кафки, смотрим на баланс и уменьшаем его, если не уйдет в минус. При конкрентном вычислении, оба потока обработчика получат один и тот же снапшот, кто то добавит в кафку ивент СписаноСБаланса первым, а второй все еще будет ориентироваться  на уже устаревший снапшот и будет lost update problem.
Я думаю вы прекрасно занаете эту проблему, я просто описал кейс для примера.
Как это разрешить, если сделать кафку ивент хранилишем для ивент сорсинга?

Ссылочку почитаю, спасибо

Я так понимаю ответ может быть: делать один поток на один стрим/агрегат, получится однопоточная обработка, только в таком случае “ну нужны локи”
То есть по сути это будут пессимистичные локи на уровне обработчика

из-за чего может пропасть consumer группа с кластера?