Kafka consumer без аккуратного retry быстро превращается в фабрику дублей.

Kafka consumer без аккуратного retry быстро превращается в фабрику дублей.

Что происходит: consumer читает сообщение, падает на обработке, offset не коммитится. Брокер видит неуспешное чтение и отдаёт событие снова. На практике это даёт:
- повторную запись в БД;
- дубль postback;
- повторный запуск webhook;
- расхождение метрик между логами и витриной.

Если упростить, у вас есть 3 точки контроля:
1. commit offset — когда фиксируете, что сообщение обработано;
2. idempotency key — чтобы повторный запуск не менял результат;
3. retry topic / DLQ — чтобы не гонять битое сообщение по кругу бесконечно.

Критичный кейс: consumer успел выполнить side effect, но упал до commit. Итог — при рестарте сообщение прилетит снова. Поэтому логика должна быть построена так, чтобы повторная обработка была безопасной, а не «на авось» ⚙️

Нормальная схема: сначала логируем событие и correlation id, потом проверяем, не обрабатывали ли его уже, затем выполняем действие, и только после этого коммитим offset. Иначе получите не сбой, а тихое размножение данных.