А зачем в ерп стримы ? База и кеш в ерп уже есть .

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

Да, в erp уже с прошлого века есть некое подобие стримовой архитектуры, когда добавления записей в  ledger порождают обновления таблиц с агрегированными значениями!

просто обрабатывая их в стримах

ещё до всяких кафок так и делали

В ерп обычно делают ивент на таблицу полупроводки . Подписка на это ивент обновляет кэш. В этом случае даже Кафка не нужна. Она тут выглядит излишней т.е можно решить задачу проще

с этим согласен

с другой стороны, вот Леруа Мерлен льёт в кафку  данные из  Navision в своих магазинах не спроста

Наверное это у него средство обмена данными между чем-то

как я понял из их доклада, для них это средство получить агрегированные данные о запасах и оборотах по всем магазинам, и спланировать таким образом поставку. Это такая мета-ERP у них получается. НО, опять же. Эта задача проходит под предложенный мною критерий

Для планирования подвоза товаров на ближайшую неделю не так важно знать, какие обороты были год назад

и ещё менее важно, какими они были два года назад)

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

плюс репроцессинг старых данных решает вопрос с "старыми" ошибками

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

@irasikhin , спасибо за мнение. Да, действительно, эти ограничения можно обойти так как вы говорите, вопрос, насколько это неудобно, насколько с этим можно/невозможно жить, чтобы не бросаться в омут data streaming с головой.

мы сейчас живем в такой парадигме kafka -> kafkastreams -> mongodb/mssql, где кафка единый источник правды
на самом деле так жить не очень просто по нескольким причинам:
- не хватает экспертизы, из за этого например разработка идет медленней
- цена ошибки в проектировании выше чем при старте с обычной RDBMS + cache, например для решения ошибок с схемой данных нужно переливать исправления в другие топики
- отсутствие read consistency, data race, ну все проблемы не ACID решения
- возможно еще что-то забыл
Зато есть плюсы:
- интеграция разных систем из коробки, подключайтесь к кафке, делайте свою реплику данных либо просто процессте данные в виде стрима
- встроенный репроцессинг позволяет относительно не сложно исправить старые данные и залить их во всем нужные системы
- сервисы не зависят друг от друга, т е часть сервисов может не работать и это может никак не отразиться на работе других систем
- нету всяких service мешей и т д, вот кафка, вот топики - работайте

ну это навскидку что вспомнил

Спасибо за комментарий!!

Ребята всем привет!
может кто подсказать
мы хотим чтобы все продюсеры писали в кафка через схему регистри
если мы правильно настраиваем наш продюсер с указанием схема регистри то  все работает согласно схеме и нет возможности отправил левое сообщение
но если мы подключаемся продюсером без указания схема регистри и с json сериализатором (например) то он может писать в тотже топик любые сообщения
вопрос в том можно ли глобально на уровне самого брокера кафки ограничить таких продюсеров
чтобы она принимала только правильно настроенных продюсеров по схеме а остальным возвращала ошибку?

Нельзя
Но можно написать библиотеку-обертку над клиентом кафки и сделать schema registry обязательным параметром

Можно. Confluent Server может делать server-side schema checks