Kafka редко ломает систему в лоб — чаще проблемы появляются в месте, где consumer «вроде бы» всё уже обработал

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

Наткнулся на разбор одной типичной ловушки: retry в Kafka Consumer — не просто техническая деталь, а часть контрактов между сервисами. Если не зафиксировать, где именно считается успех, что делать при частичной обработке и как отделять временную ошибку от необратимой, система быстро уходит в серую зону. 🔁

Практический вывод простой: retry нельзя проектировать «на потом». Нужны понятные правила для idempotency, DLQ, backoff и ручного разбора спорных сообщений. Иначе Kafka начинает вести себя не как надёжный транспорт, а как генератор трудноуловимых дублей.

Для больших контуров это особенно чувствительно: чем больше интеграций и асинхронщины, тем дороже ошибка в одном consumer’е.