Понял. Спасибо всем

Сервис таски из камунды можно пачками при помощи rest забирать. Размер пачки/таймаут - можно регулировать частоту обращения к камунде. Видел решения когда external таски самой камундой пушились в промежуточный брокер, а уже оттуда выбирались на исполнение, но в таком решении есть свои минусы.

По идее я также планировал сделать. Какие минусы вы видете ?

Возможно я не прав, я еще не сильно спец по камунде. Но вижу ситуацию так:  наверняка у вас будет ОДИН процесс, который будет выбирать ExternalTask и раскладывать по очередям/топикам, при запросе он будет указывать ОДИН workerID и ОДИН lock duration. Тут сразу вы теряете гибкость настройки локов  (разные таски могут выполняться разное время) и worker id (если что-то пошло не так, понять кто конкретно выполняет таск будет то еще расследование. Т.е. по хорошему еще какой-нибудь ELK и сквозное логирование), Если процессов будет несколько, то с добавлением новых тасков, вам придется править код или усложнять логику.   + сопровождение кластера брокера, мониторинг, репликации, персист и прочие радости.
Пока штатный REST выполняет свою задачу и с ним нет проблем, зачем усложнять? Использование любого инструмента должно решать определенную проблему, какую проблему будет решать промежуточный брокер?

А зачем экстернал таск вообще процессом выбирать?

Просто листнер на сервис таски глобальный, который параметры из таска шлёт в кафку

имеется в виду java/kotlin thread. видимо неудачно выразился

Все работает как работает прямо щас + екстернал таск ещё и из очереди можно услышать

А в чем профит работать через очереди?

Коннектов избежать как раз

Это большая проблема?

Я так понял, что в кластере камунды можно выделить несколько нод с rest starter бута, которые будут только рест запросы обрабатывать, и не обрабатывать бизнес процессы

Не, не большая

Если не ошибаюсь, у kafka в документации отмечено, что при определенном стечении обстоятельств возможны дубли сообщений. И это может стать проблемой в бизнес процессе

Это я хз, вроде как раз exactly one delivery гарантирует

one delivery да, но одно и то же сообщение может быть записано в топик дважды. если producer не получит подтверждение

https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/

Durability in Kafka depends on the producer receiving an ack from the broker. Failure to receive that ack does not necessarily mean that the request itself failed. The broker can crash after writing a message but before it sends an ack back to the producer. It can also crash before even writing the message to the topic. Since there is no way for the producer to know the nature of the failure, it is forced to assume that the message was not written successfully and to retry it. In some cases, this will cause the same message to be duplicated in the Kafka partition log, causing the end consumer to receive it more than once.

Да хрен с ней, можно в реббит или куда там писать

Не принципиально

Кафка даёт писать и читать пачками. Не все брокеры дают такую возможность. Тут нужно учитывать производительность