Нюансы паттерна Retry — 16 февраля 2026 г. в 21:32:05.019
Нюансы паттерна Retry Ещё одна классная статья от Яндекса, на этот раз о особенностях паттерна Retry. Она продолжает тему идемпотентности (если не читали, начните с неё — вот [/8|ссылка на пост]) и объясняет, как простое решение может создать множество проблем в высоконагруженных системах. Сам по себе Retry прост как пять копеек: запрос упал — нужно повторить. Но всё становится гораздо интереснее, когда мы начинаем говорить о конфигурации повторов в высоконагруженной системе. ⭐ Интересные идеи ➡ Если API идемпотентное, запросы можно безопасно повторять, и внедрение Retry может быть хорошим решением. Однако простые перезапросы могут вызвать так называемый retry storm, который добьёт сервис, которому уже не очень хорошо. В качестве решения стоит использовать exponential backoff — экспоненциальное увеличение времени ожидания между повторными попытками. ➡ Следующий подвох: если сервису стало плохо, его клиенты могут синхронизироваться даже с учётом exponential backoff и начать слать пачки запросов в одно и то же время. В таком случае используется jitter — дополнительная случайная задержка в паузах между ретраями, которая помогает уменьшить вероятность повторного скопления запросов. ➡ Если сервис будет в нерабочем состоянии слишком долго, то даже exponential backoff не спасёт. Он лишь отложит нагрузку, но при длительном даунтайме она рано или поздно начнёт расти каскадно и точно добьёт систему. Решение: использовать паттерн Circuit Breaker. В качестве альтернативы можно использовать бюджет на ретраи, но этот подход усложняет логику клиента. Также в тексте упоминаются ещё несколько интересных паттернов, о которых я напишу позже. Приятного чтения! ➖➖➖➖➖➖➖➖➖➖➖ // Понравился пост? Ставь 💛 // И обязательно подпишись на канал, чтобы не пропустить новые статьи