Circuit Breaker: когда системе пора перестать пытаться
Recommendation Service лежит.
Но каждый пользовательский запрос всё равно пытается получить рекомендации:
— отправляет запрос;
— ждёт timeout;
— делает retry;
— снова ждёт.
Пользователь тем временем смотрит на spinner и размышляет, у какого конкурента каталог работает быстрее.
Retry полезен, когда сбой кратковременный. Но если сервис действительно недоступен, повторные попытки только увеличивают задержку и создают дополнительную нагрузку.
В этот момент нужен Circuit Breaker — автоматический выключатель между системой и проблемной зависимостью.
У него три состояния.
Closed
Всё работает нормально. Запросы отправляются в Recommendation Service, а Circuit Breaker следит за ошибками и задержками.
Единичный timeout ничего не меняет: сбои случаются. Но если ошибок становится слишком много, выключатель переходит в следующее состояние.
Open
Запросы в Recommendation Service временно не отправляются вообще.
Система не ждёт заведомый timeout и не запускает бессмысленные retry. Она сразу возвращает fallback или продолжает работу без рекомендаций.
Это важно не только для пользователя. Упавший сервис получает время на восстановление, а не новую волну запросов от клиентов, которые очень настойчиво проверяют, не стало ли ему лучше.
Half-open
Через некоторое время Circuit Breaker пропускает несколько пробных запросов.
Если они проходят успешно, соединение возвращается в состояние Closed. Если снова падают — выключатель открывается ещё на один период.
Получается простой цикл:
Closed → ошибок стало слишком много → Open → прошло время → Half-open → сервис восстановился или снова Open.
Но самое интересное здесь не сам паттерн.
Допустим, рекомендации недоступны. Действительно ли из-за этого должен перестать работать весь магазин?
Вместо бесконечного spinner можно:
— скрыть блок рекомендаций;
— показать популярные товары;
— использовать последние успешно рассчитанные данные;
— дать пользователю продолжить покупку без персонализации.
Circuit Breaker отвечает на вопрос: когда перестать обращаться к сломанной зависимости.
А архитектура системы должна ответить на следующий: что делать без неё.
Это уже graceful degradation — способность системы терять часть функций, но сохранять основную ценность для пользователя.
Какая необязательная зависимость у вас сегодня способна положить весь пользовательский сценарий?
Recommendation Service лежит.
Но каждый пользовательский запрос всё равно пытается получить рекомендации:
— отправляет запрос;
— ждёт timeout;
— делает retry;
— снова ждёт.
Пользователь тем временем смотрит на spinner и размышляет, у какого конкурента каталог работает быстрее.
Retry полезен, когда сбой кратковременный. Но если сервис действительно недоступен, повторные попытки только увеличивают задержку и создают дополнительную нагрузку.
В этот момент нужен Circuit Breaker — автоматический выключатель между системой и проблемной зависимостью.
У него три состояния.
Closed
Всё работает нормально. Запросы отправляются в Recommendation Service, а Circuit Breaker следит за ошибками и задержками.
Единичный timeout ничего не меняет: сбои случаются. Но если ошибок становится слишком много, выключатель переходит в следующее состояние.
Open
Запросы в Recommendation Service временно не отправляются вообще.
Система не ждёт заведомый timeout и не запускает бессмысленные retry. Она сразу возвращает fallback или продолжает работу без рекомендаций.
Это важно не только для пользователя. Упавший сервис получает время на восстановление, а не новую волну запросов от клиентов, которые очень настойчиво проверяют, не стало ли ему лучше.
Half-open
Через некоторое время Circuit Breaker пропускает несколько пробных запросов.
Если они проходят успешно, соединение возвращается в состояние Closed. Если снова падают — выключатель открывается ещё на один период.
Получается простой цикл:
Closed → ошибок стало слишком много → Open → прошло время → Half-open → сервис восстановился или снова Open.
Но самое интересное здесь не сам паттерн.
Допустим, рекомендации недоступны. Действительно ли из-за этого должен перестать работать весь магазин?
Вместо бесконечного spinner можно:
— скрыть блок рекомендаций;
— показать популярные товары;
— использовать последние успешно рассчитанные данные;
— дать пользователю продолжить покупку без персонализации.
Circuit Breaker отвечает на вопрос: когда перестать обращаться к сломанной зависимости.
А архитектура системы должна ответить на следующий: что делать без неё.
Это уже graceful degradation — способность системы терять часть функций, но сохранять основную ценность для пользователя.
Какая необязательная зависимость у вас сегодня способна положить весь пользовательский сценарий?