в общем я в этой схеме вижу только одну проблему - целесообразность и оверинжинирг. я бы точно так не стал так делать, для этого нужны какие-то веские по более "ну может потом это всё  будет асинхронно".
и, кстати, каким боком здесь Kafka Stream появился?

Sergey, вот есть доклад с highload, видимо как раз тот вариант, который вам нужен https://www.youtube.com/watch?v=mQiS-_fzTbc&ab_channel=HighLoadChannel

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

фильтр по correlationId? у мне нет какого-то релевантного опыта по Kafka Stream, но подозреваю, что так не делают :). скорее у сервиса, который держит http-соединения должна быть в памяти таблица соответствия соединения своему correlationId и фильтрация будет уже по этой таблице

Добрый день, подскажите пожалуйста бест практис,
Задача в том чтобы реализовать взаимоедействие вебклиента с микросервисным бакендом, где микросервисы общаются  между собой с помощью 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 на фронте)?

Клиент же реактивный, подозреваю?  И тогда никакой синхронный http ему и не нужен, проще request получить через http (и там, конечно, просто rest level 1), а ответ получить через подписку на websockets, склейку и сам клиент может сделать.
Это будет гораздо масштабируемее и проще в реализации в конечном итоге.
Единственное - нужно будет как-то обеспечивать надежные очереди для websockets, но для этого есть вполне себе набор внешних решений

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

Решалась какая-то задача или оверинжиниринг ради оверинжиниринга?

Решалась задача надёжности и прогнозируемости доставки каждого сообщения до сервисов и между сервисами

я слышал что стек TCP/IP тоже неплохо справляется с этой задачей )

Все сервисы должны знать друг друга и быть в онлайне