Первый и второй это какие случаи? Если у нас 1

сервис = 1 консумер группа, то результат одинаковый.
Если одна группа на несколько сервисов, то тогда да, будет проблема. Но не понятно для каких задач такая логика может быть нужна т.к. это противоречит концепции групп.
Изначально речь шла про группу на топик, что не имеет смысла. К этому и был вопрос.

Ну да, тут я погорячился)) 1 сервис = 1 группа) Голова уже еле ворочается)

Всем привет. Хочется вернуться к этой дискуссии. Нет, все таки лучше, когда 1 топик = 1 консюмер группа. Только что еще раз увидел и осознал, что это больно выглядит. Абстрактная ситуация, 1 сервис на 200 подов читает 60+ топиков. Представляется везде одной группой. Каков шанс, если один из подов задумается (большое сообщение или еще чего), что вся вычитка встанет? Можно ведь просто сделать, в имя консюмер группы добавлять префикс/постфикс имя топика

а как так получилось что 1 сервис читает 60+ топиков? желание все про кафку упихать в одно место?

Абстрактно, это может быть жирный сервис, который используется для сбора сырья в даталейк. А если использовать концепцию 1 сервис = 1 консюмер группа, то оно как то разбивается о сущность бытия)) Вот и хочется для начала в сообществе поселить зерно раздора и убедится, что идея 1 топик = 1 консюмер-группа, правильная идея:) Либо, если идея такая себе, то хочется услышать критику по этому поводу

консумер группа - делает одну задачу, если для выполнения задачи вам надо читать из разных топиков, то одна группа должна быть на тех кто читает из них. Разные задачи - разные группы. И тут неважно в составе одного "сервиса" или нет

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

под задачей понимается что-то решающее бизнес потребность. Собственно чтение из кафки это не задача, это один из шагов в решении этих самых бизнес потребностей. Собственно тут "взять данные и преобразовать в другой вид" это (под)задача, которая например позволяет уже на основе нового вида данных сделать алертинг. В такой подзадаче явно определено какие именно данные взять, как именно, в какой вид преобразовать и куда деть и.или что по пути сделать - вот такой набор по факту определяет каждый сервис на вашем проекте, каждый делает чтото свое