Ретрай без экспоненты — это очередь в сторону 5xx и дубли в бухгалтерии

Ретрай без экспоненты — это очередь в сторону 5xx и дубли в бухгалтерии

Если вебхук упал, не надо бить его молотком каждую секунду. Нормальная схема: фиксируем попытку, ставим retry_count, а следующую доставку откладываем по экспоненте: 1s, 2s, 4s, 8s, 16s. Чтобы не устроить синхронный шторм, добавляем jitter — случайный сдвиг, иначе все хендлеры проснутся одновременно и начнут ловить 5xx на ровном месте.

Критично разделять ошибки:
— 2xx — подтверждение, событие можно пометить как доставленное
— 4xx на вашей стороне — обычно не ретраим, кроме 429
— 5xx и таймауты — ретраим, но с потолком по попыткам и по времени жизни события

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

Практический минимум: очередь для ретраев отдельно от основной, dead-letter после исчерпания лимита, метаданные с last_error и next_attempt_at. И не забывайте про backoff cap: бесконечная экспонента — плохая шутка, если провайдер лежит часами.

Смотрим в тело запроса, ставим лимиты на попытки и не путаем доставку с обработкой. Ретрай-политика решает всё: без нее любой внешний API быстро превращается в генератор дублей.