Мы сейчас разрабатываем систему лояльности, в которой создаются фильры событий,

которые связываются с кафка топиками и с flink sql
Дальше весь этот поток данных нужно как читать из топиков
Пока что пришли к мысли, что нужно создать рантайм процесс, который создает одного коньсюмера, читатет N топиков и выполняет свою логику, которая сейчас не особа важна для обсуждения
Возник вопрос, как управлять поведением системы, если хочется удалить бизнесовый фильтр событий
Подумали, что нужно тогда и топики удалить?
А что будет с рантайм процессом, если он будет читать несуществующий топик?)

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

avro+shema-regesstry

Один консюмер на несколько топиков плохо скейлится. Если нужно будет к одному из топиков накинуть партиций, то при скейлинге сервиса у вас будет или слишком много, или слишком мало консюмеров в группах, что будет приводить к бесполезным ребалансировкам. Я бы прямо за правило буравчика брал: один топик = один сервис-консюмер.

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

А один топик -> несколько консюмеров? Мне казалось, в этом один из юзкейсов кафки, например если у меня на одни и те же данные несколько разных представлений/агрегаций

если это одна консьюмер-группа, и в ней число консьюмеров = числу партиций у топика - можно добиться параллелизма вашей обработки

Я говорил про разные группы. Разные сервисы, которые обрабатывают один и тот же поток и делают разные проекции данных.

Один топик на несколько групп нормальная история. Топик скейлится партициями, группы скейлятся так же.

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

да, именно это и имел в виду

Хорошо, просто после мысли 1топик = 1 консюмер, я подумал может это уже анти паттерн)

Мысль была не такая. Мысль в том что в идеале один сервис = один консюмер