Kafka любит порядок. Но у consumer’ов есть тихая зона риска: повторная обработка сообщений.

Kafka любит порядок. Но у consumer’ов есть тихая зона риска: повторная обработка сообщений.

Внешне это выглядит как техническая мелочь. На практике — источник дублирования операций, расхождения в отчётности и лишних инцидентов между командами. Сообщение может быть обработано повторно не потому, что система «сломалась», а потому что бизнес не зафиксировал, что считать успешной доставкой, а что — уже повтором.

Типовой кейс: сервис получил событие, начал обработку, не успел корректно подтвердить offset, упал или ушёл в timeout. Для Kafka это не трагедия. Для бизнеса — уже повод для двойного списания, повторного уведомления клиента или неконсистентных данных в downstream-системах. ⚠️

Проблема обычно не в брокере, а в договорённостях между разработкой, продуктом и операционными командами: где граница идемпотентности, кто отвечает за дедупликацию, какой SLA у повторной доставки, и какие инциденты считаются допустимыми.

Именно здесь технический риск превращается в управленческий. Без формализованной политики обработки повторов любой event-driven контур рано или поздно начнёт производить не события, а споры.