Kafka умеет тихо подложить мину в проде: сообщение уже обработали, а consumer внезапно получил его ещё раз.

Kafka умеет тихо подложить мину в проде: сообщение уже обработали, а consumer внезапно получил его ещё раз.

Чёрный кейс из межсервисных коммуникаций: если в потоке нет жёсткой идемпотентности, retry превращается в двойные списания, дубль-уведомления и повторные записи в CRM. Визуально всё «почти нормально», пока не копнёшь по метрикам:
— spike по количеству обработок на 1 сообщение;
— расхождение между offset commit и фактом записи в БД;
— рост DLQ/ошибок без явного падения throughput.

Главная ловушка: Kafka гарантирует доставку, а не «ровно один раз» в вашем бизнес-смысле. Если consumer упал после сайд-эффекта, но до commit — сообщение придёт снова. Если retry не ограничен и нет дедупликации по message key/operation id, вы сами размножаете инцидент.

Что забирать в свою воронку сервисов:
1) делайте обработку идемпотентной;
2) храните dedup key;
3) разделяйте ретраи и фатальные ошибки;
4) мониторьте не только lag, но и повторную обработку.

Иначе «надёжный брокер» превращается в фабрику дублей 🔥