Ретраи без экспоненты — это очередь на повторный провал, а не надёжность

Ретраи без экспоненты — это очередь на повторный провал, а не надёжность

Если хендлер падает на временной ошибке, повторять запрос нужно не сразу, а с растущей задержкой. Иначе вы добиваете внешний API шипами, ловите 5xx на ровном месте и превращаете локальный инцидент в распределённый пожар.

Базовая схема: 1-я попытка — сразу, затем 1s, 2s, 4s, 8s, 16s. Дальше нужен потолок: max delay и max attempts. Без этого ретрай-политика решает всё, только в пользу чужого антиабуза. Добавьте jitter, иначе все воркеры проснутся одновременно и синхронно ударят по одному и тому же endpoint.

Ретрай имеет смысл только для transient-ошибок: timeout, 429, часть 5xx, сетевые обрывы. На 4xx, кроме 408/409/429, повтор обычно бесполезен. Полезную нагрузку сохраняйте целиком, а стейт прокидывайте через метаданные: попытка, причина сбоя, timestamp, idempotency_key. Идемпотентность — это не роскошь, а база.

Если у вас нет очереди, хотя бы пишите pending-задачи в durable storage и отделяйте приём вебхука от повторной доставки. Синхронный retry в HTTP-ответе — плохая идея: клиент ждёт, upstream висит, а вы держите соединение за горло.

Финал простой: сначала классифицируйте ошибку, потом решайте, ретраить или ронять в dead-letter. Иначе вы не чините интеграцию, а просто откладываете отказ на следующий цикл.