Если в сервисах есть Kafka, рано или поздно упираешься не в сам брокер, а в поведение consumer’ов при сбоях. Я

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

На практике retry — это не просто «попробовать ещё раз». Если не продумать логику, одно и то же событие может пройти через обработку повторно, создать дубль, запустить лишнюю запись в БД или сломать цепочку зависимостей 🔁

У Kafka здесь есть важная особенность: она отлично доставляет события, но ответственность за идемпотентность, дедупликацию и сценарии восстановления ложится на нас. И именно в consumer’ах чаще всего всплывают ошибки, которые не видны на этапе базовой интеграции.

Я для себя давно вывел простой принцип: если сообщение может обработаться повторно, это не исключение, а нормальный сценарий. Значит, его нужно проектировать сразу — с учётом ретраев, dead-letter queue и понятного поведения при частичных сбоях.

Именно на этом ломаются многие «стабильные» интеграции ⚙️