RETRY В KAFKA — ЭТО НЕ «ЕЩЁ РАЗОЧЕК», А ПРЯМОЙ ПУТЬ К ДУБЛЯМ И ПАНИКЕ

RETRY В KAFKA — ЭТО НЕ «ЕЩЁ РАЗОЧЕК», А ПРЯМОЙ ПУТЬ К ДУБЛЯМ И ПАНИКЕ

Kafka в двух словах: сервисы швыряются событиями через распределённый журнал. Красиво, пока consumer не решает, что сообщение надо переварить повторно. И вот тут начинается тендерная классика: все уверены, что «ну мы же просто попробуем ещё раз», а потом ловят повторную обработку, дубли в данных и сломанные ожидания по идемпотентности.

Проблема не в самом retry. Проблема в том, что его часто встраивают без расчёта последствий:
— где именно хранится offset;
— что будет при падении между обработкой и коммитом;
— как отличить реально новое событие от повторного;
— кто платит за дубль: сервис, БД или бизнес.

Если у вас consumer без идемпотентности, retry — не страховка, а генератор инцидентов ⚠️

В нормальной риск-оценке это место должно быть отмечено красным ещё до запуска. Иначе потом вместо «устойчивой архитектуры» получаете ручную сверку, странные цифры в отчётах и вопрос: «а почему это сообщение обработалось дважды?»