Kafka у нас часто стоит между сервисами как обычный транспорт. Пока всё идёт по happy path, про неё вспоминают

Kafka у нас часто стоит между сервисами как обычный транспорт. Пока всё идёт по happy path, про неё вспоминают редко. Но одна деталь в consumer’ах регулярно вылезает в инциденты — повторная обработка сообщений.

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

Типовой кейс из проекта: сервис пишет в БД, потом шлёт событие дальше. Если между этими шагами нет идемпотентности и явной стратегии retry, получаем повторное выполнение побочных эффектов. И уже не важно, что сама Kafka работает корректно — ошибка лежит в логике consumer’а.

Я обычно смотрю на это как на схему из трёх слоёв:
1) идентификатор сообщения и дедупликация;
2) контролируемый retry с понятным лимитом;
3) dead letter topic для того, что не удалось обработать.

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