Инсайд из команд, которые уже живут с Kafka не первый месяц: самая неприятная проблема в consumer’ах часто не

Инсайд из команд, которые уже живут с Kafka не первый месяц: самая неприятная проблема в consumer’ах часто не в падении сервиса, а в повторной обработке сообщений.

Снаружи это выглядит как мелочь. Сообщение уже прилетело, бизнес-логика отработала, всё зелёное. А потом — повторный запуск, дубль, неожиданная запись, лишний платёж или второй сценарий в цепочке. И вот у вас не «технический нюанс», а сбой в контентной логике сервиса: один event — два результата. ⚠️

Почему это важно для SMM/продуктовой инфраструктуры? Потому что здесь хорошо видно правило любой системы: если нет ясной модели обработки, нет и предсказуемого результата.

Нормальная схема всегда упирается в 3 вопроса:
1. что считается успешной обработкой;
2. где хранится состояние повторов;
3. как система понимает, что сообщение уже было применено.

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

Хорошая матрица обработки — это не про сложность, а про управляемость: один вход, один итог, понятный retry-policy и измеримый KPI по ошибкам. Иначе вы строите не систему, а генератор дублей.