Ретрай без дисциплины превращает вебхук в DDoS самому себе

Ретрай без дисциплины превращает вебхук в DDoS самому себе

Проблема не в самом повторе, а в том, когда и как он делается. Если внешний API ловит 500, ваш хендлер не должен молотить его в лоб каждые 200 мс. Нужна экспоненциальная задержка: 1s, 2s, 4s, 8s, с потолком и джиттером, иначе все клиенты синхронно проснутся и устроят очередь в одну дверь.

Базовая схема простая: • 5xx, таймауты, сетевые ошибки — в retry queue; • 4xx, кроме 429, — обычно в dead letter; • 429 — ретрай только с учетом Retry-After, если заголовок есть; • максимальное число попыток фиксируем сразу, а не “пока не пройдет”. Идемпотентность — это не роскошь, а база: ключ события, dedupe-таблица, проверка state перед записью.

Не забывайте про backoff cap и jitter. Без случайного смещения ретраи выстраиваются в шеренгу и бьют в один и тот же сервис в один и тот же момент. Рабочий вариант: full jitter или decorrelated jitter, плюс отдельный таймер на долгие повторы. Для критичных цепочек полезно прокидывать стейт через метаданные: attempt, first_seen, last_error, correlation_id.

Если ретрай-политика не описана письменно, она у вас уже есть — просто плохая. Смотрим в тело запроса, логируем причину отказа, ставим потолок задержки и делаем graceful fail в DLQ. Это дешевле, чем ловить 5xx на ровном месте и потом разбирать, кто именно размножил один битый пакет в тысячу повторов.