pub/sub вроде много лет существует, решает реальные задачи и на http реализовывается слабо

а в чем проблема в очередях для вебсокетов, если из кафки читаем и сразу пушаем в сокет?

Человек навелосипедил паб/саб на кафке для синхронного общения между сервисами и даже умудряется продавать это бизнесу ))

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

я так понимаю, что если у нас при переподключении заново запрашивается состоние для клиента и оно собирается, то по сути это неважно

Это дорого: при каждом въезде в туннель весь стейт перезапрашивать

А на чем еще делать pub/sub?

Добрый день, подскажите пожалуйста бест практис,
Задача в том чтобы реализовать взаимоедействие вебклиента с микросервисным бакендом, где микросервисы общаются  между собой с помощью Kafka.

вопрос в первую очередь, как реализовать синхронное взаимодействие в виде request/reply ?

Думали сделать такой вариант: веб клиент генерит corellationId и выполняет запрос к бэку например createBook,
далее логика такая
1. бакнед подписывается на топик кафка book-created  спомощью KafkaStreams делает filter по key=correlationId
2. бакнед отпарвляет команду CreateBookCmd в топик кафка book-create и среди прочего передает correlationId
3. далее какой-то консьюмер обрабатывает команду из топика book-create, создает Book и генерит BookCreatedEvent  в топик book-created
4. бакенд получате событие из топика book-created с нужным corellationId и затем отдает ответ на вебклиента.

в таком сценарии получается что на каждый запрос  вебклиента создается новый короткоживущий экземпляр KafkaStreams и вызывается start , stop
вопрос насколько ресурсоемко создание экземпляров KafkaStreams на каждый запрос от вебклиента?
как я понимаю такое решение аналогично созданию консьюмера для топика  book-created с последующим чтением всех событий и отбрасыванию с несоотвсвующими corellationId.
Соответсвенно вопрос  насколько ресурсоемко создание коньюмера на каждый запрос от вебклиента?

Может быть есть более правильные паттрены (что бы уйти от request/reply на фронте)?

Сделали подобное решение (request/reply через kafka) - работает очень надёжно, однако пришлось реализовать свою библиотеку, которая закрывает от разработчика все хитрости обмена (подписка на партиции нужных response-топиков, поиск и закрепление нужных партиций, разбивка и склейка фреймов данных)

это, видимо, RPC поверх очередей (такое было модно в RabbitMQ). вот только вопрос, если в каком-то процессе сервиса мы отравили request но не дождались replay и сервис упал, после переподнятия этого сервиса мы же уже не сможем обработать этот replay?  или библиотека это как-то обыгрывает?

Если request-сервис упал ДО получения reply-сообщения, то после его восстановления сообщение не будет им обработано - такой у нас сценарий, но это легко исправить, если нужно, путем, например, добавления промежуточного состояния request с correlationId и serviceId в топике Kafka - решается легко

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

вот что-то мне кажется, что это не так легко исправить в сценарии с RPC.  если это была асинхронная модель взаимодействия, то мы бы отправили Request сохранили бы состояние процесса и забыли бы про него, пока к нам не придет Replay и уже тогда подняли бы сохраненное состояние процесса и обработали этот Replay. в RPC состояние между запросом/ответом не сохраняется - в этом его смысл.