Я не в москве
Если и не на свалке, то поржавели в любом случае. Какого они года выпуска "не в Москве" ?

Задача больно простая.

Моя оценка _работоспособного_ кода для "сервера", от 200-300 строк, т.е. первая версия - человеко день с базовыми знаниями Java backend и просмотра пары примеров (даже чтения документации на данном этапе не нужно).

Что бы настроить раббит, нужно хотя бы прочитать документацию по нему, думаю страниц под 300-500, после чего настроить интеграцию шины сообщений между раббит и DMSB_AQ. Т.е. скорее всего нужно будет компилить какой нибудь "модуль интеграции" в те же самые 200-300 строк, но написанных другим человеком, т.ч. разбираться в чужом коде + читать документацию (если она вообще есть). Потом настраивать раббит. Потом тестировать, работает ли он. Потом писать прием/отсылку сообщений в раббит и так далее. Для меня, для получения первой работоспособной версии, потребовалось бы не меньше недели.

_Только_стандартным_ кодом все равно не обойдется, т.ч. какие-то велосипеды придется прикручивать/дописывать (та же интеграция), плюс будет задействован чужой код (сложно разбираться с проблемами) и т.д и т.п. Трудоемкость и сложность системы возрастают, а результат тот же. Никакого профита (кроме новомодных слов в резюме разработчика) не видно.


Что кафка, что раббит, что другая MQ - думаю однофиолетово


Требование про "гарантировать доставку" при Вашем описание проблемы, звучит очень странно. Ну потеряется одно _информационное_ сообщение из тысячи, job отработает, но пользователь об этом вовремя не узнает. В чем потеря для бизнеса, если пользователь узнает об этом не сразу, а через десяток минут?

Например в нашей задаче, это явно не критично. Т.к. с большей вероятностью: пользователь забудет открутить колонки на максимум; сильно заснет (не услышит колонок); проснется, автоматом нажмет на Ok и заснет снова; и так далее и тому подобное....

Ну отреагирует диспетчер на заявку не через 5 минут, а через полчаса. Возможно это и плохо, но врят ли критично.

Будет _реально_ критическая авария, нормальный адекватный сотрудник, кроме заявки через IT систему еще по телефону позвонит и не только (не столько) диспетчеру, сколько своему непосредственному руководителю (если совсем серъезно, то руководитель позвонит своему, тот еще выше, генеральный позвонит губернатору и так далее).

Если же кто-то настолько полагается на IT-систему в _критических_ ситуациях, то боюсь, в _реально_ _критических_ ситуациях такую отмазку ни губернатор, ни президент, ни следственный комитет не примет.

Т.ч. что там кафка гарантирует, что не гарантирует - для бизнеса однофиолетово. IMHO





1) rabbitmq / кафка / что-то еще - модно, современно, технологично, но по первому взгляду на описанние задачи - слишком переусложненно.

Кроме собственно разработки системы, ее еще потом нужно поддерживать / дорабатывать. Т.е. rabbitmq / кафку / что-то_еще должен не только текущей программист знать / выучить (ему то наверное даже по приколу будет, он на данной задаче свои скилы повысит), но и людям, которые дальше будут эту систему поддерживать (следующее поколение программистов, системный администратор и так далее), а это уже прямые затраты $$$ организации при сопровождении системы.

2) hc.apache - самое просто и легковестное

3, 4) Netty и GRPC - как я понимаю, это более-менее полноценные web / servlet сервер / контейнер. Можно взять и его, но по сравнению с hc.apache, опять таки, более тяжеловестно. Если знаете какие-то технологии типа spring.boot (я ее _не_ знаю) и считаете, что на данной технологии Вам сделать проще, чем на чистой Java + hc.apache - ради бога. Если вместе с ней "впридачу" идет Netty / GRPC - то возражений нет. Но тащить полноценный web / servlet сервер туда, где нужно просто слушать и отвечать на одно-два URI, _немного_ тяжеловестно. (с netty не работал, знаю только tomcat/Weblogic; про grpc даже не слышал)

5) Соккеты - самое-самое легковестное и не требует никаких сторонних библиотек, больше ни одного плюса по сравнению с http, одни минусы.

p.s. например наш код-оповещалки общается с java-bean внутри легаси приложения (OeBS) именно через сокеты. Т.к. чем меньше стороннего кода (библиотек) в легаси запихано, тем лучше. Х.з. как OeBS себя поведет и что ему в сторонних библиотеках не понравится. Т.ч. только чистый Java, никаких (минимум) библиотек. Но если таких жестких ограничений нет, то HTTP конечно лучше.

P.S.
Еще один расказ из жизни.

Наш генеральный очень сильно в течении 2-3 лет хотел "шину сообщений". Перед программистами была поставлена задача
1. сделать шину сообщений
2. придумать куда ее впихнуть (что бы при этом все еще продолжало работать)
3. реализовать

Программисты данную задачу провалили. Т.ч. впихнуть шину куда нибудь и можно было бы, но:
1. все и так уже работает без всяких шин
2. всюду, куда пытались бы впихнуть, выглядило бы это ну просто жутко уродливо (плюс см. п.1)
3. не было гарантий, что если перейти на шину, то соответствующий функционал продолжить работать без сбоев. Даже несмотря на то, что данная шина 100500 раз "гарантирует доставку сообщений"

В общем - программисты не справились.

Почему генеральный директор ставил такую задачу и был готов ее оплачивать в виде ЗП:
1. "Шина сообщений" это "модно и молодежно". Даже генеральные деректора такие слова слышали, хотя плохо представляют, что же это такое - можно продать
2. Преднозначена для интеграции - значит можно попытаться впихнуть нашу шину и в наши, и в чужие проекты
3.
3.1. Если мы разработаем такую шину, все остальные, даже закупив очень много бутылок по 0.5 литров - фиг разберутся )))
3.2. Т.к. ее будем запихивать куда надо и не надо - без нее все гарантированно накроется медным тазом
3.3. В результате - фиг наш обойдешь в каких нибудь последующих тендерах. Президенты меняются, губернаторы меняются, а хорошо написанная шина - может жить и давать зарплату сотрудникам вечно.

Если же такой аргументации нет, то раббит, шины и прочее - из пушки по воробьям

IMHO