Сценарий простой: сообщение уже было обработано, но consumer упал, offset не зафиксировался — и привет, повторная доставка. Если обработка неидемпотентная, вы получаете дубли, гонки, сломанные статусы и весёлый цирк в логах.
В WordPress-мире это очень похоже на кривой cron, который запускает одну и ту же задачу три раза: письма уходят дважды, заказы дергаются повторно, данные в БД становятся мусором. Баг не выглядит как катастрофа, пока не прилетает в прод.
Что надо проверять:
1. Идемпотентность обработки
2. Когда именно фиксируется offset
3. Что происходит при timeout и restart
4. Есть ли dead-letter queue для проблемных сообщений
5. Не маскируете ли вы ошибку бесконечным retry 🔥
Повторная обработка — не “редкий edge case”. Это штатная причина инцидентов. И если consumer не умеет переживать дубли, то виноват не Kafka. Виноват код.
WP Surgery
@WpSurgeryPro
Kafka любит ломать спокойную жизнь, когда consumer начинает жрать одно и то же сообщение по кругу.
Этот пост опубликован в Telegram-канале WP Surgery. Подписаться можно по ссылке: @WpSurgeryPro.