Kafka любят подавать как “надёжную трубу”: сообщение ушло — значит, всё обработается. На практике у consumer’а

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

Контринтуитивный вывод: проблема не в том, что Kafka “плохо доставляет”, а в том, что люди путают доставку с выполнением бизнес-операции. Kafka гарантирует порядок и сохранность в рамках своей модели, но не превращает ваш код в exactly-once без дополнительных ограничений.

Что это значит для продукта и денег? Один дубль в логике “списать бонусы”, “создать заказ”, “начислить cashback” — и метрика уже искажена. Воронка выглядит лучше или хуже реальности, retention шумит, а финансы получают лишние операции 💥

Правильный вопрос не “как убрать retry”, а “как сделать обработку идемпотентной”. Потому что в distributed-системах повтор — не исключение, а базовый риск. И если это не заложено в дизайн, рано или поздно оно вылезет в проде.