Kafka consumer может неожиданно начать «жевать» одно и то же сообщение повторно — и это не баг брокера, а норм

Kafka consumer может неожиданно начать «жевать» одно и то же сообщение повторно — и это не баг брокера, а нормальная часть модели доставки. Если consumer успел прочитать запись, но не подтвердил offset, после рестарта или rebalance сообщение придёт снова.

Как это устроено:
- Kafka хранит события в логе, а не “удаляет после чтения”
- подтверждение идёт через commit offset
- если commit не дошёл, получаем at-least-once delivery
- значит, дубликаты — штатная ситуация, а не авария ⚙️

Что важно на практике:
1. Обработчик должен быть идемпотентным
2. Для side effects нужен дедуп по message id / business key
3. Commit лучше делать после успешной обработки, а не до
4. На длительных задачах следить за max.poll.interval.ms, иначе consumer вылетит из группы и сообщение уйдёт на повтор

Типовой сценарий проблемы: запись в БД прошла, а commit offset — нет. После рестарта consumer снова читает тот же event и пишет его второй раз. Поэтому в бою Kafka почти всегда требует защиту от повторов на уровне приложения.

Мини-чеклист:
- есть unique key в БД
- есть таблица processed_events
- есть retry/DLQ для “ядовитых” сообщений
- логируете offset, partition, key

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