Ретраи без экспоненты превращают вебхук в DoS против самого себя

Ретраи без экспоненты превращают вебхук в DoS против самого себя

Если внешний API отвечает 500, 502, timeout или рвёт TCP, не долбите его в лоб. Сразу ставьте backoff: 1s, 2s, 4s, 8s, с потолком и джиттером. Иначе тысячи одинаковых хендлеров проснутся одновременно и устроят stampede — красивый способ добить и себя, и соседа.

Смотрим в тело запроса и отделяем ошибки:
• 4xx, кроме 429 — обычно не ретраим: payload битый, токен мимо, схема не совпала.
• 429 и 5xx — ретрайим, но с лимитом попыток и таймаутом на весь job.
• network error / EOF / broken pipe — ретрайим, но считаем это недоставкой, а не успехом.

Идемпотентность — это не роскошь, а база. Каждый webhook event должен иметь ключ: event_id, delivery_id или хэш полезной нагрузки. Перед повторной обработкой проверяйте дедуп в Redis/PostgreSQL, иначе экспоненциальная задержка просто размножит дубликаты с красивой паузой между ними.

Схема рабочая: handler принимает запрос, быстро кладёт задачу в очередь, отдаёт 2xx, а ретраи живут уже в воркере. Для каждого шага храните номер попытки, причину отказа и next_retry_at. Если лимит исчерпан — отправляйте в DLQ, а не в бесконечный ад с автоповторами.

Ретрай-политика решает всё: без потолка, джиттера и дедупликации любая интеграция рано или поздно начнёт бить сама себя по голове.