Ретрай-политика без дисциплины — это DDoS самому себе

Ретрай-политика без дисциплины — это DDoS самому себе

Если хендлер падает, не надо молотить его в лоб тем же payload. Базовая схема: фиксируем попытку, сохраняем idempotency key, отвечаем 2xx только после записи в очередь или БД. Иначе внешний сервис решит, что всё ок, а вы потом будете ловить фантомные события в пайплайне.

Экспоненциальная задержка — не просто sleep(2^n). Нужен jitter, иначе все клиенты проснутся одновременно и устроят синхронный шторм. Нормальная формула: base * 2^attempt + random(0, spread). Для критичных интеграций добавляют cap, чтобы ретраи не уехали в бесконечность.

Что обязательно проверять:
— 4xx обычно не ретраим, кроме 408, 409 и некоторых 429.
— 5xx и сетевые ошибки — кандидат на повтор.
— Дедупликация по event_id или hash полезной нагрузки.
— Dead letter queue, если попытка исчерпана.
— Логируйте attempt, next_retry_at, upstream_status.

Если сервис обещает ретраи сам, не верьте на слово: дубли прилетят, тайм-ауты пересекутся, а порядок событий поплывёт. Прокидываем стейт через метаданные и считаем обработку не успешной, пока не завершены все сайд-эффекты.

Сначала защита от дублей, потом задержка, потом лимиты. Идемпотентность — это не роскошь, а база.