Блокирующий повтор в обработчике держит партицию: одно проблемное сообщение задерживает все следующие. Retry-топики уносят сообщение на повтор с задержкой, а партиция продолжает обрабатываться.
А ещё Spring Kafka: @RetryableTopic
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Порядок в партиции обрабатывается последовательно, поэтому пауза перед повторной попыткой — это простой для всех сообщений позади. При экспоненциальной задержке в десятки секунд задержка обработки становится катастрофической. Схема с retry-топиками работает иначе: сообщение перекладывается в отдельный топик с нужной задержкой, а основной поток сразу продолжает работу; часто заводят несколько топиков с нарастающими задержками, а после исчерпания попыток сообщение уходит в DLQ. Плата за это — потеря исходного порядка для перенесённых сообщений, и её нужно проговаривать: схема подходит там, где строгий порядок между независимыми сущностями не требуется.
Один верный вариант. Подумайте, потом откройте ответ.
Что повторять и почему не всё, backoff/jitter, non-blocking retry, дизайн DLQ и redrive, идемпотентность как фундамент.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto