Повторная обработка сообщений в Kafka Consumer — это не «страховка», а источник скрытых багов.

Повторная обработка сообщений в Kafka Consumer — это не «страховка», а источник скрытых багов.

Мейнстрим-совет звучит просто: если consumer упал, переотправим сообщение и всё доедет. На практике повтор почти всегда ломает логику, если обработка не идемпотентна. Одно и то же событие может:
— создать дубль;
— дважды списать лимит;
— отправить два одинаковых уведомления;
— испортить аналитику по конверсиям 📉

Ошибка здесь не в Kafka, а в ожидании, что очередь сама решит бизнес-логику. Не решит.

Что делать вместо «просто retry»:
1) разделять временные и фатальные ошибки;
2) делать обработку идемпотентной;
3) хранить статус уже обработанных событий;
4) выносить повторные попытки в отдельный dead-letter / retry pipeline.

И главное: retry нужен не для того, чтобы «дожать любой ценой», а чтобы не потерять событие без контроля. Если это не продумать заранее, система начнет выглядеть стабильной — ровно до первого инцидента ⚠️