Если по одновременным подключениям, то не думаю что больше 200, но потом появятся IoT. Но у нас есть уже задача реализовать что то наподобие совместного редактирования документа, отображением изменений онлайн, поэтому стали думать в сторону EventSourcing.

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

А зачем вообще kstream?

фильтрация сообщений в топике делается оч просто с помощью стримов

KStream<String, String> source = builder.stream("book-created");
KStream<String, String> filtered = source.filter((key, val) -> key.equals(correlationId));
       
       filtered.foreach((key,value)->{
           System.out.println(value);
       });

А что при этом внутри происходит?

Не происходит - результат в новый топик записывается (если надо)

Зачем создавать короткоживущие клиенты, почему нельзя сделать долгоживущие? То есть в api сервисе хранить список клиентов (открытых соединений) и когда из топика прилетает создание, то отвечать соответствующему клиенту. На первых порах можно чтобы каждый инстанс сервиса читал полный топик создания, в последствии можно реализовать кастомный партишонер. Но как писали выше - эту версию придется реализовать для каждого ЯП

не совсем понятно. Если основная задача - реализовать совместное редактирование , то можно взять CRDT?

Зачем создавать короткоживущие клиенты, почему нельзя сделать долгоживущие? То есть в api сервисе хранить список клиентов (открытых соединений) и когда из топика прилетает создание, то отвечать соответствующему клиенту. На первых порах можно чтобы каждый инстанс сервиса читал полный топик создания, в последствии можно реализовать кастомный партишонер. Но как писали выше - эту версию придется реализовать для каждого ЯП

но он же все на клиента тянет и на клиенте фильтрует, а не на брокере?

Это еще в кафке или уже в rocksdb?

Java приложение. Для фильтрации rocksdb не нужен

то есть это просто сахар над пропуском получаемых консьюмером сообщений? Или тут оффсет не сдвигается?
Т.е. как это реализовано, какие внутри гарантии и производительность?

то есть это просто сахар над пропуском получаемых консьюмером сообщений? Или тут оффсет не сдвигается?
Т.е. как это реализовано, какие внутри гарантии и производительность?

Но на каждый KStream создается своя consumer group, да?

Но на каждый KStream создается своя consumer group, да?