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 — способность системы терять часть функций, но сохранять основную ценность для пользователя.

Какая необязательная зависимость у вас сегодня способна положить весь пользовательский сценарий?