Kafka-ошибки почти всегда выглядят как «мелкий технический инцидент». До тех пор, пока consumer не начинает по

Kafka-ошибки почти всегда выглядят как «мелкий технический инцидент». До тех пор, пока consumer не начинает повторно прогонять одно и то же сообщение.

Я считаю retry одной из самых недооценённых точек репутационного риска в продукте. Не потому что Kafka плохая. Потому что бизнес обычно видит только симптом: задвоение действий, странные статусы, повторные письма, лишние списания, шум в саппорте. А причина лежит глубже — в том, как система переживает сбой.

Жёсткий вывод простой: если у вас нет внятной политики повторной обработки, у вас не «надёжная интеграция», а лотерея под нагрузкой. 🔁

Что нужно держать в голове:
— retry без ограничений = риск бесконечного цикла;
— retry без дедупликации = повторное действие для клиента;
— retry без мониторинга = инцидент заметят не инженеры, а пользователи.

Для кризисной коммуникации здесь один принцип: не спорить с фактом, а быстро назвать рамку. Что повторилось, кого затронуло, как остановили, когда исправим. Это и есть взрослый response, а не «мы уже разбираемся».