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

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

Смотрим в тело запроса и решаем: ошибка временная, постоянная или мусор от клиента. 5xx и сетевые таймауты — кандидат на retry, 4xx обычно надо класть в dead letter и разбирать отдельно. Идемпотентность — это не роскошь, а база: event_id, request_id или hash полезной нагрузки должны отсеивать дубли.

Экспоненциальная задержка работает только вместе с jitter. Иначе все клиенты просыпаются одновременно и снова лупят в упавший хендлер. Хорошая схема: delay = base * 2^attempt, сверху cap, плюс random jitter. Это сглаживает пики и дает внешнему API шанс восстановиться.

Не делайте бесконечные ретраи в лоб. Ограничивайте число попыток, ведите счетчик в метаданных, а после исчерпания переводите событие в очередь ручной разборки. Если полезная нагрузка зависит от времени, добавляйте TTL: просроченный заказ не должен воскресать из очереди через час и ломать пайплайн.

Ловим 5xx на ровном месте не героизмом, а дисциплиной: классификация ошибок, backoff, jitter, дедупликация и понятный failover. Если этого нет, то ретраи просто размножают инцидент.