В Kafka большинство команд всё ещё смотрит на retry как на «техническую мелочь». Ошибка.

В Kafka большинство команд всё ещё смотрит на retry как на «техническую мелочь». Ошибка.
Повторная обработка сообщений — это не про надёжность в вакууме, а про стоимость дублей, latency и реальный ROI сервисов.

Если consumer падает и вы просто перечитываете offset, вы не «чините» доставку. Вы часто создаёте:
— повторные side effects
— раздувание очередей
— ложную стабильность в метриках
— сложности с идемпотентностью на уровне бизнес-логики

Contrarian-позиция простая: retry надо проектировать не вокруг Kafka, а вокруг критичности операции. Для одних потоков нормален at-least-once с дедупликацией. Для других дешевле отдельный retry-topic, backoff и ручной разбор poison messages. Иногда лучший retry — это вообще no retry, а быстрый fail и перенос ошибки в наблюдаемую систему.

Kafka не спасает плохой workflow. Она просто делает его масштабным.