Kafka часто воспринимают как «просто очередь сообщений», но в проде важнее другой вопрос: что делать с повторн

Kafka часто воспринимают как «просто очередь сообщений», но в проде важнее другой вопрос: что делать с повторной обработкой.

Если consumer не успел обработать событие, упал или вернул ошибку, сообщение может прийти снова. И это не баг, а нормальная часть работы с брокером. Проблема начинается, когда повторная доставка не учтена в логике продукта и сервиса.

Что важно помнить:
1. **Доставка в Kafka не равна exactly once по умолчанию.**
Нужна защита от дублей на уровне consumer’а и бизнес-логики.

2. **Повторная обработка влияет на user impact.**
Один и тот же заказ, списание или уведомление может выполниться дважды, если не заложить идемпотентность.

3. **Retry — это часть архитектуры, а не технический хвост.**
Нужно заранее решить: где повторяем, сколько раз, с какой задержкой и когда уводим сообщение в dead letter queue.

4. **Отдельно проверяйте side effects.**
Запись в БД, отправка пуша, вызов внешнего API — все это разные сценарии риска и разные правила ретрая.

Для продуктовой команды вывод простой: если событие критично для денег, статусов или коммуникации с пользователем, retry должен быть описан в требованиях так же явно, как основной happy path. ⚙️