Retry queues

Retry-очереди откладывают повторную обработку после сбоя. Задержку делайте через TTL и hop в DLX, отдельные delay-очереди или плагины брокера — избегайте плотных циклов, бьющих по downstream. Храните число попыток, время первого сбоя и последнюю ошибку в заголовках или отдельной таблице.

Ограничьте максимум попыток и направляйте исчерпанные сообщения в dead-letter для ручного разбора. Экспоненциальный backoff с jitter размазывает retry-шторм после аварий. Политика retry должна быть явной по типу сообщения: платежи и email-уведомления ведут себя по-разному.

На интервью: нарисуйте трёхступенчатую retry-лестницу, объясните роль jitter и определите, когда повтор не нужен.

Типовые ошибки: бесконечные retry poison-сообщений; повтор неидемпотентных эффектов без дедупликации; фиксированная задержка и синхронный thundering herd; отсутствие видимости глубины retry.

Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.

Чеклист:

• Лимит попыток на тип сообщения.
• Backoff с jitter.
• Сохранение метаданных попыток.
• Исчерпание → DLQ с контекстом.