Ретрай с задержкой (Retry with delay)

Паттерн retry with delay: повтор запроса после временного сбоя с паузой и джиттером. Не замена failover и не сага.

Ретрай с задержкой (retry with delay) — паттерн надёжности на слое вызова: повтор того же запроса после временного сбоя, с паузой и джиттером, без смены контура.

На каком слое надёжности работает «Ретрай с задержкой»

Вызов: повтор того же запроса после временного сбоя.

Какой отказ моделирует паттерн «Ретрай с задержкой»

кратковременная недоступность: потеря пакета, перегруз на секунды, рестарт зависимости. Цель после паузы, скорее всего, снова жива.

Что изолирует «Ретрай с задержкой» и где кончается радиус взрыва

радиус одного вызова. Не изолирует арендаторов и не переключает контур. Ошибка, которая не временная (4xx прикладной, порча данных), не должна ретраиться.

Когда паттерн «Ретрай с задержкой» применять нельзя

если цель мертва — снимайте её и смотрите Резервирование. Если повтор без джиттера и лимита — усиливаете каскад. Нельзя ретраить неидемпотентную операцию без ключа идемпотентности.

Что записать в архитектурное решение (ADR) про «Ретрай с задержкой»

какие коды/условия временные, сколько попыток, закон паузы, бюджет времени, идемпотентность.

Оценка качеств «Ретрай с задержкой»: масштабируемость, надёжность, сопровождение

Звёзды — ориентир автора сайта, не бенчмарк и не сравнение продуктов.

  • масштабируемость: ⭐⭐⭐ (3/5)
  • надежность: ⭐⭐⭐⭐⭐ (5/5)
  • сопровождение: ⭐⭐⭐⭐⭐ (5/5)

Варианты протокола «Ретрай с задержкой» и как выбрать

  • Фиксированная пауза: просто, легко совпасть всем клиентам в один удар.
  • Экспоненциальная пауза с джиттером: размазывает повтор, это и есть «retry with delay», а не «retry сразу три раза».
  • Ретрай на краю (шлюз) vs в приложении: два слоя ретрая без общего бюджета = шторм.

Схема взаимодействия: как работает «Ретрай с задержкой»

sequenceDiagram
    participant Клиент
    participant Сервис
    Клиент->>Сервис: запрос
    Сервис--xКлиент: временный сбой
    Note over Клиент: пауза с ростом и джиттером
    Клиент->>Сервис: повтор
    Сервис-->>Клиент: успех
попытка = 0
пока попытка < лимит:
    ответ = вызвать(зависимость)
    если временный(ответ):
        ждать(пауза_с_джитом(попытка))
        попытка += 1
    иначе:
        вернуть ответ

Типичные ошибки при внедрении «Ретрай с задержкой»

  • Повтор без джиттера и без потолка — ретрай-шторм по уже больному сервису.
  • Ретрай на клиенте и на шлюзе независимо, бюджет времени никто не считает.
  • Повтор POST без ключа идемпотентности.

С какими паттернами не путать «Ретрай с задержкой»

  • Резервирование — другой контур после смерти цели, не третий удар в тот же труп.
  • Bulkhead — лимит одновременных вызовов; retry без bulkhead легко исчерпает общий пул.
  • Сага (SAGA) — компенсация шага процесса, не пауза HTTP.

Источники для сверки формулировок про «Ретрай с задержкой»

В практике отказоустойчивости облака retry policy к API провайдера — отдельная рекомендация рядом с health check, не замена вывода мёртвой цели. Yandex Cloud — рекомендации по отказоустойчивости.

Частые вопросы про «Ретрай с задержкой (Retry with delay)»

Когда retry with delay применять нельзя?

Если цель мертва — её снимают и смотрят failover. Нельзя ретраить неидемпотентный запрос без ключа и без лимита попыток: получите шторм.

Зачем джиттер в повторных попытках?

Фиксированная пауза синхронизирует клиентов. Экспоненциальная пауза с джиттером размазывает повтор по времени.

Чем retry отличается от саги?

Retry — пауза одного вызова. Сага — компенсации бизнес-шагов на нескольких сервисах.