Согласен, если оставаться просто джавистом, далеко не уедешь. ) Лучше стать разработчиком.
Управление восстановлением в Кафке, конечно, требует некоторого погружения в тему. Но в целом, как сказано далее, это компромисс между скоростью и надежностью. Можно увеличить, к примеру, в настройках количество реплик, помня об издержках репликации. Или ask установить на all (что снизит пропускную способность). А потом подключить мониторинг метрик (к примеру, Графану/Прометеус) и посмотреть, как это скажется на производительности.
Можно найти и другие технологии работы с очередями. Но по-любому, придется "вылезать из скорлупы" и юзать окружение: докеры-"шмокеры" и прочее. На одной джаве и реляционных базах не удасться продержаться сейчас.

Если кафка пугает, можно Spring Cloud Stream RabbitMq.

Полностью поддерживаю это беспокойство. Если ломается БД - у нас есть 100% документированные механизмы
восстановления незакоммиченных данных и главное... есть саппорт и есть вменяемая оценка по срокам.

В случае с кафкой, как мы видим у джавистов - нулевой опыт восстановления сбойных хранилищ. И тут любое неверное
движение или неверно понятая документация - и данные ресетнулись и месседжинг покатился с нуля. А возможностей
прокачать подобный опыт у джавистов мало - т.к. технологий очень много а ситуации когда надо восстанавливать
файловые структуры - бывают редко.

По срокам тут - вообще непонятно. Продуктовая система не может стоять на паузе пока джависты делают investigation
что за ситуация и как вообще из нее выходить. И главное где провисли эти сообщения и как их восстановить если какой
то API радостно сообщает сто сбой контрольной суммы файла или блока и что дальше делать непонятно.

Согласен, если оставаться просто джавистом, далеко не уедешь. ) Лучше стать разработчиком.
Управление восстановлением в Кафке, конечно, требует некоторого погружения в тему. Но в целом, как сказано далее, это компромисс между скоростью и надежностью. Можно увеличить, к примеру, в настройках количество реплик, помня об издержках репликации. Или ask установить на all (что снизит пропускную способность). А потом подключить мониторинг метрик (к примеру, Графану/Прометеус) и посмотреть, как это скажется на производительности.
Можно найти и другие технологии работы с очередями. Но по-любому, придется "вылезать из скорлупы" и юзать окружение: докеры-"шмокеры" и прочее. По-любому придется столкнуться.[/quot]

не понял, почему само себе будет слать. Можете более детально обрисовать?

в Кафке больше компонентов. Поэтому, на мой взгляд, больше возможных сценариев сбоя.

По-любому очередь в вашем случае будет двунаправленной. Я это изначально предполагал, но теперь в этом все больше убеждаюсь.
Я так понимаю, б24 будет возвращать апп2 данные по 100 товарам одним пакетом? Это было бы логично. И если так, то в единицу времени б24 будет принимать гораздо больше запросов от апп2, чем апп2 ответов от б24. В случае кафки здесь два топика. В разделы первого апп2 записывает сообщения, читаемые б24. В разделы второго б24 уже записывает ответы, читаемые апп2.
Ну, если я правильно понял ваш замысел.

Кстати, а принципиально, чтобы апп2 читал ответы от б24 в том же порядке, в каком направляет в нее запросы?