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

Может быть есть смысл делать коммит перед началом вычитки нового куска?

То есть консюмер приходит за новым оффсетом и перед этим комитит старый

Идея хорошая, единственное в идеале отследить бы это и сделать по одному разу для каждой из партиций

Но это уже дело техники

вот мне коллега говорит, что у топика с оффсетами retention есть не только по времени, но и по размеру,  упорно не могу нагуглить про размер , ни как посмотреть,  ни как задать

Гуглите retention.bytes

Ну и cleanup.policy должна быть delete.
По дефолту нет ограничения по размеру, только по времени.

В моем понимании там compaction, и оно выглядит как KV. Для большинства жизненных ситуаций очень сложно по размеру переполнить

Compaction это про отчистку места путем удаления старых записей с тем же ключом. Это допустимо только в определенных случаях, с определенной бизнес логикой.
Когда же важна вся последовательность сообщений, compaction применить нельзя.
В тоже время, есть ситуации когда для топиков с compaction имеет смысл применять delete полиси, т.к. множество ключей неограничено и редко повторяется, например uuid с редкими повторениям.

В любом случае, применение обоих типов retention: по месту и времени, хорошая практика. Дает предсказуемость максимального размера топика на диске и максимального времени доступности сообщений

Мы же про топик с офсетами все еще говорим?

Хм, я в целом, отфильтровал что мы про системный топик.
Не трогайте его вообще, там умные люди все посчитали :)

Я про тоже, очень сложно придумать кейс, когда с ним (топик с офсетами) что-то пойдёт не так

Если приложение-консьюмер редко читает или упало на какое-то время, при малом ретеншене будет проблематично корректный офсет. Актуально больше для ранних версий (до 2.0), когда дефолтный ретеншн был сутки

Спасибо!!!

А у мы смогли!!! :)

Привет, у меня такой вопрос. Допустим, у меня один консьюмер обслуживает 2 партиции, у одной партиции оффсет ушел значительно вперед по какой-т причине. В итоге, одна партиция читается в реальном времени, а у второй есть лаг. Как консьюмер, обслуживающий обе партиции будет распределять между ними объем вычитанных данных, поровну, или больше читать с отстающей партиции?

советую почитать этот кип