Короткий ответ
Сервис при недоступности опциональной зависимости продолжает отдавать урезанный, но полезный результат (например, без персональных рекомендаций) вместо полного отказа всего запроса, когда деградировавшая часть не критична для основной функции.
Как это работает подробнее
Код явно выделяет «обязательные» и «опциональные» зависимости для запроса; при сбое опциональной используется fallback (кешированное/дефолтное значение), а при сбое обязательной — явная ошибка.
Пример кода
example.py
def get_product_page(product_id):
product = get_product_core(product_id) # обязательно, без fallback
try:
recommendations = get_recommendations(product_id, timeout=1)
except (TimeoutError, CircuitOpenError):
recommendations = [] # деградация — страница рендерится без блока рекомендаций
return render_page(product, recommendations)Что использовать на практике
- Практика. Решение, какая зависимость опциональна, принимается на уровне бизнес-требований; fallback часто комбинируют с circuit breaker — при открытом breaker сразу используется fallback без попытки реального вызова.
Подводные камни
- Риск. Делать весь запрос зависимым от самой нестабильной подсистемы, хотя она лишь дополняет контент; не тестировать сценарий деградации отдельно — fallback-код часто остаётся непроверенным.