Ретрай без стратегии превращает вебхук в DDoS по собственному API

Ретрай без стратегии превращает вебхук в DDoS по собственному API

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

Базовый контракт простой:
• повторяем только на сетевых ошибках и 5xx;
• 4xx считаем окончательным фейлом, кроме явного 429;
• на каждом ретрае сохраняем idempotency key и номер попытки;
• максимальное число попыток фиксируем заранее, без бесконечной надежды на чудо.

Полезная нагрузка должна быть безопасной для повтора. Если хендлер уже создал заказ, отправил письмо или списал деньги, повторный вызов не должен плодить дубль. Прокидываем стейт через метаданные, проверяем дедупликацию по event_id, а результат первой успешной обработки пишем в хранилище до ответа 200. Идемпотентность — это не роскошь, а база.

Практика для очереди: отдельный retry-queue, dead letter queue и метрика по причинам отказов. Не смешивайте бизнес-ошибки с временной недоступностью: у них разная судьба. Ретрай-политика решает всё: без неё вы не лечите сбой, а размножаете его.