Повторная обработка сообщений в Kafka Consumer — хороший пример того, как «маленькая техническая деталь» превр

Повторная обработка сообщений в Kafka Consumer — хороший пример того, как «маленькая техническая деталь» превращается в продуктовый риск.

Что происходит: consumer получает сообщение, не успевает корректно обработать его с первого раза — и оно уходит в retry. На уровне системы это выглядит нормально, но для бизнеса может означать дубли, задержки в обновлении статуса, повторные письма или пуши.

Где чаще всего ломается опыт:
- клиент уже завершил действие, а сервис ещё раз пытается его обработать;
- событие уходит в повтор, но без понятного дедупликационного ключа;
- ретраи растягивают время до value moment, и пользователь видит «зависший» процесс.

Что важно проверить:
1. Идемпотентность обработки — одно сообщение не должно менять состояние дважды.
2. DLQ и лимиты retry — чтобы ошибка не гонялась бесконечно.
3. Логику порядка событий — особенно в онбординге, оплатах и re-engagement.
4. Наблюдаемость — чтобы видеть не только факт ошибки, но и её влияние на customer journey 📉

Хороший retry — это не «переусердствовать с надёжностью», а сохранить предсказуемый опыт для пользователя.