Гипотеза недели: если consumer в Kafka настроен «надежно», это не значит, что одно сообщение обработается ровн

Гипотеза недели: если consumer в Kafka настроен «надежно», это не значит, что одно сообщение обработается ровно один раз.

Что обычно происходит на практике:
- сообщение уже попало в топик;
- consumer начал обработку;
- сервис упал, таймаут, ребаланс или ошибка в downstream;
- offset не успел зафиксироваться;
- сообщение приходит повторно.

Итог — дубли в бизнес-логике. В омниканальных сервисах это быстро превращается в лишние списания, повторные статусы и расхождение в отчетах.

Схема проблемы простая:
1) чтение из Kafka
2) обработка
3) commit offset
4) сбой между шагами 2 и 3 = retry

Ключевой вывод: в Kafka нужно проектировать не «exactly once по умолчанию», а идемпотентную обработку. То есть закладывать повторное сообщение как нормальный сценарий, а не как редкую аварию 🧩

Практический чек:
- есть ли у сообщения уникальный ключ;
- умеет ли consumer безопасно переживать дубль;
- что происходит при частичном фейле;
- где хранится факт обработки.

Если этого нет, retry — не техническая деталь, а источник расхождения метрик.