Fallback — это стратегия, при которой система при сбое основного сервиса переключается на запасной сценарий, чтобы пользователь не увидел ошибку, а получил хоть какой-то результат.

Простая аналогия - навигатор
Идеальный сценарий:
- Навигатор получает данные о пробках в реальном времени
- Показывает оптимальный маршрут с учётом аварий, ремонтов дорог и плотности трафика
- Перестраивает маршрут динамически, если ситуация меняется
Fallback (Когда что-то пошло не так):
- Потеряно соединение с интернетом →
- Навигатор показывает сохранённую карту и базовый маршрут без учёта пробок
- Да, вы можете попасть в затор, но вы хотя бы доедете до точки назначения.

Как это работает?
Обычно работает в связке с Circuit Breaker и Timeout:
1. Делаем запрос к основному сервису (например, к сервису рекомендаций).
2. Если ответ не пришел за 500мс (Timeout) или пришла ошибка...
3. ...включаем Fallback:
- Берем данные из локального кэша.
- Показываем статический список ("Популярное").
- Возвращаем значение по умолчанию.

Когда ПРИМЕНИМО?
✅ Нужна высокая доступность (High Availability)
→ Сайт должен работать всегда, даже если часть функций отвалилась.
✅ Допустима неактуальность данных
→ Лучше показать цену товара часовой давности, чем ошибку "503".
✅ Грейсфул деградация (Graceful Degradation)
→ Мы не "рушим" весь сайт из-за падения виджета с погодой.
✅ Пиковые нагрузки
→ Если основной сервис не справляется, включаем упрощенный режим.
Когда НЕ ПРИМЕНИМО?
❌ Критичные финансовые операции
→ Нельзя возвращать "фейковый" баланс или "успешную оплату", если она не прошла.
❌ Данные должны быть строго актуальными
→ В медицинских системах или системах бронирования "старые данные" могут стоить здоровья или денег.
❌ Пользователь должен знать о проблеме
→ Иногда лучше честно сказать "Сервис недоступен", чем врать, что всё ок.

Мораль:
Идеальный сервис — это мечта.
Работающий сервис — это реальность.
Fallback Pattern учит нас тому, что иногда лучше дать "кое-что", чем не дать ничего.
Главное — чтобы "кое-что" не было ошибкой. 😎