Kafka — это не “надёжный брокер, который сам всё разрулит”. Самое неприятное место там — не прод, не сеть и не

Kafka — это не “надёжный брокер, который сам всё разрулит”. Самое неприятное место там — не прод, не сеть и не лаги. А повторная обработка сообщений.

Я вижу одну и ту же ошибку у команд: consumer падает, сообщение улетает в retry, потом приходит снова, потом ещё раз — и вдруг бизнес-логика срабатывает трижды. Денег списали дважды, статус заказа прыгнул, пользователю прилетело лишнее уведомление. Красота.

Мой тезис простой: если у вас в Kafka нет чёткой стратегии retry, у вас нет контроля над поведением системы. Есть надежда. А надежда в распределённых системах — плохая архитектура.

Ретрай без idempotency, DLQ и понятной политики попыток — это не “устойчивость”, а скрытый источник инцидентов. Особенно когда разработчики мыслят в стиле: “Ну мы же обработаем ещё раз, ничего страшного”. Страшное как раз начинается потом ⚠️

Нормальная схема — это не просто “ловим ошибку и пробуем снова”. Это:
— где храним состояние попытки
— сколько раз допускаем повтор
— что считаем фатальной ошибкой
— куда уводим мусорные сообщения
— как защищаем бизнес-операции от дублей

Если этого нет, consumer у вас не надёжный. Он просто умеет повторять чужие проблемы.