Ретраи без стратегии — это штурм API лбом, а не надежная интеграция

Ретраи без стратегии — это штурм API лбом, а не надежная интеграция

Если внешний хендлер лег, не надо бомбить его одинаковыми запросами каждые 2 секунды. Держим базовую схему: 1-я попытка сразу, дальше задержка растет по экспоненте: 1s, 2s, 4s, 8s, с потолком и случайным jitter. Иначе тысячи клиентов синхронно проснутся и добьют сервис пиком. Ретрай-политика решает всё.

Важно разделять ошибки: 4xx обычно не лечится повтором, 5xx и сетевые обрывы — кандидат на повтор. Смотрим в тело запроса и в ответ: если пришел 429, уважаем Retry-After; если payload битый, уводим в dead-letter, а не крутим по кругу. Идемпотентность — это не роскошь, а база: idempotency-key или внешний event_id должны отрезать дубли на приемнике.

Практика: храните счетчик попыток и следующий timestamp в очереди или метаданных события. Прокидываем стейт через метаданные: attempt=3, next_retry_at=..., last_error=... . После N неудач — quarantine, алерт, ручной разбор. Иначе получите бесконечный цикл, который ночью выглядит как “вроде работает”, а утром — как лавина дублей.

Если делать просто: экспонента + jitter + cap + фильтр по типам ошибок + дедупликация на входе. Все остальное — декоративный шум вокруг аварии.