poll надо вызывать в цикле, нет гарантий, что вернутся все записи за 1 вызов

вычитанные записи нужно коммитить?

если это требуется приложению, то да

ок, спасибо

Не соглашусь. Батчиг скорее следствие poll модели.

А пол модель следствие чего?)

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

Вопрос вот такой. Есть kafka, nats, все как бы для микросервисов, обчитался и перепробовал. Но вот не догоняю все равно одну тему. Ну отправил я сообщение на шину, ну получил его кто то ... и... не справился, не отработал и получается все. Тот же sidekiq для рельсы, bull для ноды поверх redis будет пытаться дожать задачу, повторы и все такое. Нужно поверх kafka or nats писать проверку успешности и повторы делать?

Зачем?

Какая тебе разница получил ли кто?

бизнес процес ломается весь

Или ты рпц делаешь поверх шины?

Ну

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

Я думаю в этом чате есть эксперты по запуску RPC подобных протоколов поверх Кафки. Да @foxkids94 ?

по принципу все или ни чего (в этом раскладе, внешний пушер повторит задачу мне)

буду рад любым мнениям. уже блин устал гонять мысли из пустого в порожнее

Как всегда два подхода - это оркестрация (где есть дирежиер) или кооперация (когда сервисы сами с усами и понимаю что им надо делать)

А ты не смотрел книжку Designing event-driven systems? Неужели там нечего не удалось почерпнуть?

много читал. сейчас пробую применить. буду рад примерам каким то.  сейчас смотрю в сторону (sidekiq, bull for nodejs, как дирижеров поверх последовательности kafka с сагами).