это только через кафку. и producer'ов

насчет это я чесно говоря не был уверен раньше. но если так - тогда ок. все складывается

на лету можно поменять?

ок, тогда объясни, почему мое решение не масштрабируется?

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

“простой” и “на лету” это немного разные вещи вообще то

да признаю что со стороны кафки нужен "простой"

хотя в случае кластера кафка это будет минимизировано

ок, давай я задам несколько вопросов, чтобы ты понял, в чем ты не прав:
1. сколько консюмеров могут одновременно читать из 1 топика?
2. сколько оффсетов в 1 консюмер-группе?
3. какое отношение между сущностями “партиция” и “активный консюмер”? варианты: (а) one-to-many, (b) many-to-many, (c) many-to-one

“активный консюмер” — это консюмер, которому активно доставляются сообщения. в отличие от “пассивного консюмера”, который стоит на стреме

1. только один
2. у каждой партиции свой офсет. каждый консюмер знает свой топик и partition. а в группе может быть несколько consumer
3. не корректный вопрос, тут нельзя точно сказать какой консюмер из какого топика и из какой партиции может выбрать  следующее сообщение. consumer-group->consumer->topic->partition

1. из одного топика могут одновременно читать не более N консюмеров, где N = кол-во партиций в данном топике
2. у каждой партиции в рамках консюмер-группы свой офсет,каждый консюмер знает своИ топикИ и партициИ в этих топиках. Например у партиции может быть несколько оффсетов, но они все будут в разных группах.
3. в рамках одной консюмер-группы отношение many-to-one.

получается, чтобы масштабировать мое решение, достаточно накинуть еще много инстансов, но одновременно получать сообщения будут только N инстансов, где N = кол-во партиций

партиции можно вроде скейлить вверх ( то есть докинуть партиций )
вот убрать - не выйдет

продюсеров придется перезапустить же

разве нет?

да, конечно, но это вряд ли проблема

там есть другой проблемный поинт - что очередность потеряется

после добавления нового партишна изменится маппинг от ключей к партициям

чаще как раз в том и проблема, что продюсеров нельзя перезапускать

2. у каждой партиции в рамках консюмер-группы свой офсет,каждый консюмер знает своИ топикИ и партициИ в этих топиках. Например у партиции может быть несколько оффсетов, но они все будут в разных группах.

ето как? естьоффициальная документация? как по мне такого не может быть и не должно...