Самая недооценённая боль в Kafka — не падение брокера, а повторная обработка сообщений.
Я вижу это постоянно: команда уверена, что consumer «просто дочитает очередь», а потом внезапно получает дубли, повторные списания, двойные уведомления и сломанный user flow. И это не баг Kafka как таковой — это цена за то, что вы не продумали retry и идемпотентность заранее.
Kafka отлично работает как event log, но consumer’ы живут в реальном проде, где сеть падает, сервисы тормозят, а внешние API отвечают через раз. Если не заложить сценарий повторной обработки, вы получите не «надежную шину», а фабрику случайных повторов 🔁
Мой горячий тейк: retry — это не техническая деталь, а часть продукта. Как только сообщение влияет на деньги, уведомления или пользовательский статус, нужно проектировать не только happy path, но и что будет при втором, третьем и десятом проходе. Иначе платить за это будет уже бизнес.
UGC Crew
@UgcCrew