У меня концептуально\архитектурный вопрос. к знатокам :) Ситуация типичная. Был монолит,

постепенно откусываем от него куски, всю новую функциональность делаем отдельными сервисами(микросервисами).

Взаимодействие между микросервисами делаем через кафку. НО вопрсо как обычно в деталях. Как правильнее строить это взаимодействие?

Примеры:
1) хотим расшарить на всю систему некоторый набор сущностей(справочники и тд)

как правильнее это делать ?
Вариант 1: из источника(сервис где они создаются) льем их в кафку, все кому они нужны должны как то их получать.
Решение: каждый сервис слушает очередь с нужным справочником и сохраняет их себе в базу(получается локальный кеш). считаем поток однонаправленным, изменения только в источнике создаются.
Насколько такой вариант приемлим? из проблем сразу видно дублирование данных.


Вариант 2(похож на 1 но только на kafka store)
из кафки льем не в базу, а делаем на стороне принимающего сервиса stream application со стором.
из проблем: по сути тоже дублирование, сложность создания стором под каждый вариант выборки
из плюсов: плюсы от сторов(автоматическое создание, восстановление при сбое и тд)



Вариант 3:
делаем просто запрос-ответ
запрашивающие сервисы каждый раз через кафку дергают сервис источник "дай мне такой то справочник"

минусы:
нагрузка на сервис источник, которую можно было бы переложить на кафку,нагрузка на сеть, дублирование запросов


Подскажите как все таки правильнее организовывать такое взаимодействие?

Подскажите кто еще как использует? хочется несколько мнений услышать :)

3ий вариант я так понимаю впринципе никем не рассматривается ?

Тоже думаем над подобной архитектурой. Инжинеры Confluent сделали и продолжают делат очень много чтобы превратить Kafka в полноценную платформу для микросерфисных приложений. Собственно идея вообще не использовать внешние БД а сделать все на Кafka + Kafka Streams. Есть ряд полезных статей и даже примеры приложения на микросервисах базирующихся на Kafka Streams. Реализовал маленький сервис который работает с одной сущностью, вот дальше сервис по сложнее пока под вопросом. Собственно проблема в следующем: Допустим, есть сервис который отвечает за некие датчики, обычный справочник. Фактически информацию о датчиках загоняем в Кафку а микросервис сохраянет данные у себя в State Store он же KTable. Далее по просторму REST может отдавать эти данные на UI. Изменение данных тоже через REST -> producer -> Kafka. Но тут появляется другая сущность, "типы датчиков" , соответсвенно датчик должден быть определенного типа. В RDBMS было бы 2 таблицы и Join в Кафке заджоинить 2 KTable можно только по ключу, джоин KTable и GlobalKTable, который нам бы подошел, еще не реализован. На этом месте затык. Пока единственный выход это денормализация, хранить типы вместе с датчиками, так и передавать, и делать отдельный процесс который будет обновлять все датчики определенного типа если изненили например название типа. Сорри за много букв, возможно кто-то решал подобную задачу.