а зачем in-memory то?

разумеется

мы можем получить от кафки подтверждение того что наши логи были получены и надёжно сохранены?

А чем все-таки плох вариант с бд и каким-нибудь Kafka-jdbc или даже debezium, как уже предлагали выше?

У реббита есть такое, у кафки, насколько мне известно, нет механизма оповещения продюсеров о получении консюмерами  сообщений

ещё раз: tight coupling между конкретной бд и перекладыванием отвественности ведения event log’а на микросервис, который только бизнес логикой должен заниматься а не тем, как event log вести, сохранять и отправлять

на практике их проще делать сайдкарами + есть поддержка стримингов в них
у хейзела напрямую в кафку была вроде
можно со стороны сервиса писать в него, а там уж он сам когда нибудь откинет в кафку

ну, лог с базы как раз и тулзой делать можно, а не сервисом

всё-равно писать придётся не напрямую в бд из кода микросервиса а через некий side-car посредник

с точки зрения сложности разработки и сопровождения использование in memory грида значительный overkill

нам не лог с базы нужен, а event log 🙂 логические изменения в состоянии приложения, а не изменения таблиц и т.п.

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

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

В чем здесь принципиальная разница?

У вас же каждое событие это какое-то состояние? Или лишь его изменение?

Может я не верно понял

ack от брокера примерно оно и есть

Может быть ты в курсе про дополнительные требования Романа. Но я про клауд и другое не слышал)

А в файлик локальный писать - да, это просто, что может быть проще?

в том, что условный ROW_INSERT(table: users, values: {bla,foo,bar}) это не UserCreated{foo, bar}

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

есть разница между WAL’ом бд и логическими логами самого приложения. Мы не хотим использовать implementation detail миксервиса как сыботия для других сервисов, ибо оно может меняться, а логические события это относительно простой протокол коммуникации

писать переводчик WAL->AppLogic неоправдано дорого, проще и безопаснее хранить бд (аггрегат) и лог отдельно

Если тебе нужно парсить события из БД, то в случае, к пример binlog’ов от mysql есть возможность группировать изменения произошедшие в одной транзакции.

Знаю довольно большой и известный проект работающий на такой логике