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

kafka.
Есть идея сделать что-то типа data-provider-service который бы отдавал данные что в БД лежат а все остальные чтобы в него ходили. Но как то не оч понятно как это все асинхронно будет работать. Типа клиентский сервис кинул сообщение в топик типа дай User по id.
data-provider-service его поймал и отправил ответ. Клиентский сервис его поймал и показал профиль.
Насколько это вообще работоспособоно, есть ли у кого то практический опыт такой реализации?

Это больше на паб-саб похоже

Клиент должен ходить по REST, Kafka как внутренняя шина для общения между микросервисами. Вот пример такой архиетктуры https://www.confluent.io/blog/building-a-microservices-ecosystem-with-kafka-streams-and-ksql/ это типа хелоу ворд, в реальной жизни очень много подводных камней

> Типа клиентский сервис кинул сообщение в топик типа дай User по id. data-provider-service его поймал и отправил ответ. Клиентский сервис его поймал и показал профиль. Это звучит как обычный request-response. Зачем для этого брокер использовать? gRPC в помощь, если хочешь модно-молодёжно 🙂 Я кафку пытаюсь использовать между микросервисами, но только тогда, когда продьюсер плюёт сообщение и не ждёт ничего в ответ.

можно через кафку != кинь запрос Дай юзера, получи ответ

Мы реализовывали такую схему на вебсокетах и кафке, клиент шлет по ws сообщение в котором есть отдельное поле sequence_id, сервер обрабатывает месседж и отправляет клиенту ответ с тем же sequence_id, а клиент по этому id понимает что за ответ ему пришел, но сразу скажу, сапортать это дело адок и в последствии от этого подхода отказались в пользу инструментов имеющих нормальную request/response семантику, из полюсов пожалуй только то что процесс не блокирующий и имеет backpressure из коробки. В целом если вам не нужна гарантированная доставка то я бы сейчас смотрел в сторону RSocket он тоже не блокирующий и имеет backpressure из коробки, но при этом поддерживает request/response