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

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

При вебхуках ошибка бывает временной, а бывает фатальной. Если на любой 500 ответить мгновенным повтором, вы просто добьёте внешний сервис и свой воркер. Нормальная схема: классифицируем отказ, сохраняем событие, планируем повтор и не теряем идемпотентность.

Базовая стратегия такая:
— 4xx без 429 обычно не ретраим: полезная нагрузка битая, токен пустой, подпись не сошлась.
— 429 и 5xx — ретраим, но с экспоненциальной задержкой и джиттером, чтобы толпа хендлеров не стучала синхронно.
— Лимит попыток обязателен: после него событие уходит в dead-letter, а не крутится вечно.

Пример полезной нагрузки для планировщика:
{"event_id":"evt_123","attempt":3,"next_delay_ms":8000,"status":"pending"}
Идемпотентность — это не роскошь, а база: одинаковый event_id должен приводить к одному бизнес-эффекту. Иначе ретраи превращаются в дубль оплаты, дубль письма или дубль заказа. Для тяжёлых интеграций храните ключ обработки и результат последнего успешного выполнения.

Формула задержки простая: base * 2^attempt, но с потолком и рандомизацией. Без потолка вы получите ожидание на часы и мусор в очереди, без джиттера — эффект синхронного шторма. Ретрай-политика решает всё: сначала защитите себя от лавины, потом думайте о скорости доставки.