вот может что-то вроде такого
https://docs.spring.io/spring-kafka/reference/html/#replying-template

ReplyingKafkaTemplate не рассматривали? https://dzone.com/articles/synchronous-kafka-using-spring-request-reply-1

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

Вряд ли бестпрактис уже сформировались. И много факторов есть, которые влияют на выбор решения. Добавлю свои 5 копеек.
1. Зачем столько разных топиков? Можно реквест-респонсы складывать в один, тогда сообщения с одинаковым ключом будут в одном партишне и упорядочены по времени. Консьюмеры будут фильтровать по ключу/хидерам и брать то, что нужно им, это достаточно дешево. В блоге конфлюент есть несколько постов на эту тему.
2. В чем профит создавать короткоживущий стрим? Выглядит как усложнение в описанном кейсе. Если все происходит в рамках одного реквест-респонса с фронта, то можно обойтись консьюмером из топика/партишна и хоть в памяти сервиса держать мапу с correlationId реквестов, так как шарить ее между несколькими инстансами смысла особого нет. Рядом можно список держать с отсортированными по времени реквестами, который пригодится для чистки мапы. Вариант плох тем, что поток должен будет простаивать и проверять мапу в ожидании ответа из топика, чтобы потом его отдать на фронт. Либо нужно менять схему реквест-респонс, и, например, процесс запускать с фронта на одном эндпоинте, а потом результат спрашивать на другом, опрашивая в цикле сервис, либо вебсокеты, как уже писали выше. Но тогда уже нужно шарить данные между инстансами и использовать бд или редис какой-нибудь.

> тогда сообщения с одинаковым ключом будут в одном партишне и упорядочены по времени

так здесь нет ни какого профита от сохранения порядка, а вот skip'апть сообщения не предназначенные для обработки consum'ером respon'зов может и не так дорого, но и можно этого избежать

> Вариант плох тем, что поток должен будет простаивать и проверять мапу в ожидании ответа из топика

ну а зачем так плохо делать, если можно сделать хорошо ) не надо ждать в потоке, пока придет response, можно вернуть его в пулл и поставить какой-нибудь асинхронный lock и уже реактивно его снять, когда придет response. другой вопрос, что там надо будет учитывать всякие тайматы http-соединения, но это уже особенности реализации

добрый день, подскажите пожалуйста, если закрыть кафку логином и паролем, можно ли будет со стороны косюмера узнать с какого логина пришло сообщение?

Вряд ли бестпрактис уже сформировались. И много факторов есть, которые влияют на выбор решения. Добавлю свои 5 копеек.
1. Зачем столько разных топиков? Можно реквест-респонсы складывать в один, тогда сообщения с одинаковым ключом будут в одном партишне и упорядочены по времени. Консьюмеры будут фильтровать по ключу/хидерам и брать то, что нужно им, это достаточно дешево. В блоге конфлюент есть несколько постов на эту тему.
2. В чем профит создавать короткоживущий стрим? Выглядит как усложнение в описанном кейсе. Если все происходит в рамках одного реквест-респонса с фронта, то можно обойтись консьюмером из топика/партишна и хоть в памяти сервиса держать мапу с correlationId реквестов, так как шарить ее между несколькими инстансами смысла особого нет. Рядом можно список держать с отсортированными по времени реквестами, который пригодится для чистки мапы. Вариант плох тем, что поток должен будет простаивать и проверять мапу в ожидании ответа из топика, чтобы потом его отдать на фронт. Либо нужно менять схему реквест-респонс, и, например, процесс запускать с фронта на одном эндпоинте, а потом результат спрашивать на другом, опрашивая в цикле сервис, либо вебсокеты, как уже писали выше. Но тогда уже нужно шарить данные между инстансами и использовать бд или редис какой-нибудь.

Не совсем в тему кафки, но в тему синхронных/асинхронных взаимодействий с фронтом:
А кто-нибудь знает технологии кроме WebSocket и поллинга, чтобы асинхронно отвечать фронту в веб?

Не совсем в тему кафки, но в тему синхронных/асинхронных взаимодействий с фронтом:
А кто-нибудь знает технологии кроме WebSocket и поллинга, чтобы асинхронно отвечать фронту в веб?

Http/2 - grpc

Не совсем в тему кафки, но в тему синхронных/асинхронных взаимодействий с фронтом:
А кто-нибудь знает технологии кроме WebSocket и поллинга, чтобы асинхронно отвечать фронту в веб?

Коллеги, может быть кто-то сможет подсказать. Есть сорс коннектор, заливающий строки из реляционной таблицы в топик с тремя партициями, работает ок. В коннекторе указан mode:bulk и sql запрос. Я выполняю PUT на порт 8083, коннектор начинает работать. Как понять, что все строки из запроса добавлены в топик, то есть коннектор закончил работу и ждет?