Ретрай-политика без дисциплины превращает вебхук в генератор дублей и 5xx

Ретрай-политика без дисциплины превращает вебхук в генератор дублей и 5xx

Ретрай — это не “попробуем ещё раз”, а часть контракта между источником и вашим хендлером. Если внешний сервис шлёт одно и то же событие повторно, система должна пережить это без двойной записи, двойной оплаты и повторной отправки письма.

Базовая схема: на входе сразу проверяем идемпотентный ключ, кладём полезную нагрузку в очередь, отвечаем 2xx только после фиксации в хранилище. Если обработка упала — источник видит неуспех и запускает повтор. Если событие уже было — возвращаем тот же результат, не трогая бизнес-стейт. Идемпотентность — это не роскошь, а база.

Экспоненциальная задержка нужна, чтобы не устроить штурм падающего API. Типовой профиль: 1s, 2s, 4s, 8s, 16s с потолком и джиттером. Без случайной добавки все клиенты бьют в одну секунду, и вы ловите синхронный шторм. После N попыток — в dead letter queue, а не в бесконечный ад.

Отдельно держим ошибки по классам: 4xx с плохой нагрузкой не ретраим, 5xx и таймауты — ретраим, сетевые обрывы — ретраим, но с лимитом. Логируйте attempt_id, event_id, статус, время ожидания, чтобы ночью быстро понять, где сломался пайплайн.

Если у вас нет лимита попыток, idempotency key и DLQ, вы не строите интеграцию — вы откладываете инцидент.