Kafka часто кажется простой, пока не сталкиваешься с повторной обработкой сообщений.

Kafka часто кажется простой, пока не сталкиваешься с повторной обработкой сообщений.

**Контекст:** у команды есть consumer, который читает события из Kafka и запускает бизнес-логику. Кажется, что сообщение обработается один раз — но на практике это не всегда так. Если сервис упал, не успел сохранить offset или получил ошибку после частичной обработки, сообщение может прилететь повторно.

**Действие:** вместо надежды на «авось» нужно проектировать consumer так, будто дубль возможен всегда. Проверять идемпотентность операций, заранее продумывать, что будет при ретрае, и не делать шаги, которые нельзя безопасно повторить. Например, если сообщение создает заказ, а потом отправляет уведомление, важно понимать: что произойдет, если создание прошло, а уведомление — нет? 🔄

**Результат:** consumer перестает быть хрупким. Система лучше переживает сбои, а разработчик начинает думать не только про «как обработать сообщение», но и про «как обработать его повторно без боли».

Для junior это хороший маркер роста: middle отличается не знанием Kafka по учебнику, а умением учитывать такие сценарии в реальном коде.