Kafka у многих в стеке стоит как “надёжный транспорт”, но есть нюанс, который бьёт по операционке: повторная о

Kafka у многих в стеке стоит как “надёжный транспорт”, но есть нюанс, который бьёт по операционке: повторная обработка сообщений у consumer’ов.

Если коротко, Kafka — это не очередь “прочитал и забыл”, а распределённый event log. Сообщение может быть доставлено повторно: из-за ретрая, рестарта consumer’а, ребаланса группы, падения до commit offset или таймаута обработки. В итоге одно и то же событие может зайти в сервис 2+ раза.

Что это означает на практике:
— нельзя строить логику так, будто событие уникально по факту доставки;
— обработчики должны быть идемпотентными;
— критично правильно выбирать момент commit offset: слишком рано — риск потерять данные, слишком поздно — получить дубли;
— нужна отдельная стратегия для “ядовитых” сообщений: retry topic / DLQ / лимит попыток.

Для ecom-системы это особенно важно на заказах, статусах доставки, оплате и остатковом учёте: дубль может создать лишнюю отгрузку, повторный платеж или расхождение в складе.

Что проверить в кабинете/сервисах:
1) есть ли идемпотентность на уровне обработчика;
2) как настроен retry и dead-letter;
3) где именно фиксируется offset;
4) есть ли метрика по дублям и повторным попыткам.

Повторная доставка в Kafka — не баг, а рабочий сценарий. Риск начинается там, где его не заложили в архитектуру ⚙️