Можно ли менять offset в Kafka и стоит ли это делать?

Что проверяют

Понимаете ли вы, что offset это позиция группы потребителей в партиции, а не свойство сообщения, и видите ли последствия перечитывания для всей системы. От аналитика ждут не команды в консоли, а требований: что произойдёт с данными ниже по потоку, если сообщения обработаются дважды. Следом обычно просят описать сценарий повторной обработки в постановке.

Как отвечать

Основа:

• offset: порядковый номер записи внутри одной партиции. Уникален только в её пределах, в соседней партиции те же номера;
• зафиксированный offset: каждая consumer group хранит свою позицию в служебном топике __consumer_offsets. Сообщения неизменяемы, сдвиг позиции их не удаляет и не влияет на другие группы;
• когда меняют: перечитать данные после исправления ошибки в обработчике, загрузить историю в новый сервис, пропустить сообщение, на котором обработчик падает. Технически это seek() в коде или kafka-consumer-groups.sh --reset-offsets с --to-earliest, --to-datetime, --shift-by;
• срок хранения: перемотать можно только в пределах retention.ms (по умолчанию семь дней). Более старых данных в топике уже нет;
• новая группа: без сохранённой позиции действует auto.offset.reset, по умолчанию latest, то есть группа начнёт только с новых сообщений.

Дальше переходите к своей зоне. Типичная настройка потребителей даёт доставку «хотя бы один раз», поэтому дубли возможны и без ручного сдвига. В требованиях стоит зафиксировать ключ идемпотентности, правило дедупликации и поведение побочных эффектов при повторе: письма, списания, записи в отчётность. Для битых сообщений лучше заложить отдельный топик ошибок (DLQ), чем пропуск сдвигом.

Где спотыкаются

Говорят, что сдвиг offset вперёд удаляет сообщения. Они остаются в топике, их просто не прочитает эта группа, и вернуть их можно, пока не истёк срок хранения.

Считают offset глобальным идентификатором сообщения. Для ссылки на запись нужна пара из партиции и offset или бизнес-ключ.

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