в RMQ HA жесткая вещь, мы как обычно повесили vrrp на ноды, мастер отвалился, как-то не заметили что он половину дня провалялся, решили поднять, а тут мастер говорит слейву реплицируйся с меня и 500к сообщений в трубу, потом переехали на 3,8 с рафтом, там уже нет прямого сброса на диск сообщений, скидывается на диск и в оперативку, в итоге 128 ГБ РАМ забили и всё встало, в итоге расстроил нас раббит, до конца не хотели менять его, он хорош с dlq, шавелом и прочими плюшками, но когда много rps, то только в кафку и рисовать на ней dlq-топики, если какая-та дичь прилетела вместо ожидаемых данных

А у вас какой ha-mode?

было all, а с кворумными очередями был фокус когда ЦОД обесточился и кластер поднимался около суток, реплицировался и восстанавливал данные, сингл нода работает хорошо на раббите, а вот с кластером начинаются фокусы, плюнули и начали переезжать на кафку

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

да, для начала, но  еще второй вариант, фронт и бэк общаются через websoсket, но примерно логика та же остается.

тогда не совсем понятен профит от асинхронности "под капотом". в чем проблема сделать выполнения команды CreateBook синхронно и отдать ответ клиенту? ну а там и событие BookCreated будет отправлено и уже заинтересованные сервисы его будут обрабатывать

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

как вариант, нужен сервис меш под это дело

тут же не просто хттп вызов какой-то

ну начинается логика с простого HTTP POST вызова со стороны фронта

а вот если и на фронте должно быть всё асинхронно, то тогда запрос на бек должен только зарегистрировать команду CreateBook и уже либо отдельный метод наружу будет торчать, для пуллинга статуса выполнения команды, либо придет событие через WebSocket о изменении статуса команды.
только тут вопрос целесообразности. почему нельзя дождаться синхронно выполнения CreateBook? это слишком сложная и длительная операция, что стандартного http таймаута недостаточно?

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

а неужели нет более удачного способа получить синхронный ответ из кафки? все таки перепиливать все ресты на такой вот пуллинг звучит как-то очень странно

если все взаимодействие между сервисами через кафку сделано, то как можно синхронно дождаться то?

слушать топик на предмет появления события с нужным corellationId - тут можно и заблокироваться, а можно и асинхронно ответ отдать

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

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

но как я понимаю рекомендуют pull со стороны вебклиента делать
https://www.confluent.io/resources/kafka-summit-2020/synchronous-commands-over-apache-kafka/

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