Kafka consumer и retry — место, где легко словить дубли и сломать семантику обработки.

Kafka consumer и retry — место, где легко словить дубли и сломать семантику обработки.

Схема простая: consumer читает сообщение, делает side effect, потом падает до commit offset. Kafka считает сообщение необработанным и отдаёт его снова. В итоге:
- запись в БД может выполниться дважды;
- внешний API получит повторный запрос;
- метрики «успешной обработки» врут.

Это не баг Kafka. Это следствие модели at-least-once. Если нужен exactly-once, его не «включают галочкой»: надо проектировать идемпотентность, транзакции и границы побочных эффектов.

Что проверять:
1. Когда делается commit offset — до side effect или после.
2. Есть ли дедупликация по message key / event id.
3. Как устроен retry: синхронный, через DLQ, отдельный topic.
4. Что будет при rebalance: consumer может прочитать то же сообщение повторно.

Практический вывод: если операция не идемпотентна, retry = риск двойного действия. В проде это надо подтверждать логами и трассировкой, а не надеждой на «и так прокатит» ⚙️