Представьте ситуацию: вы смотрите стрим, и вдруг интернет становится медленным. Видео начинает тормозить, но вместо того чтобы прерваться оно автоматически снижает качество и продолжает воспроизводиться.

Такое поведение системы называется fallback. Если система перестает работать по основному варианту, то она переключается на запасной. Как в жизни: если не сработал будильник — вас разбудит кот, прыгнувший на грудь в 7 утра 😼.

Алгоритм простой: 

1️⃣ Обнаружить проблему (например, API не отвечает 5 секунд) 2️⃣ Переключить систему на запасной вариант 3️⃣ Вернуть к основному варианту, когда проблема решена

🛠 Для чего эта фича?

— Пользователь не видит ошибки. Вместо "500 Internal Error" он получает упрощенный функционал.  — Система остается стабильной даже если часть функционала упала. 

🚒 Как реализовать fallback

Важно иметь минимально рабочий вариант, который решает главную задачу пользователя даже без определенных фич.

Перед реализацией нужно задать себе вопросы: — Что пользователь хочет получить здесь и сейчас?  — Какие данные/функции критичны, а какие можно временно убрать? 

Вот несколько вариантов как реализовать этот запасной вариант:

— Кэшировать данные Показываем последние сохраненные данные (как в мессенджере: старые сообщения видны, новые грузятся позже).  — Использовать заглушки Заменяем динамический контент статичным (например, вместо живой ленты — шаблон с текстом: "Данные временно недоступны").  — Продумать альтернативные процессы Если не работает оплата картой, предлагаем наличные или ссылку на оплату позже.

🤔 Почему реализация fallback всегда разная?

Потому что всё зависит от контекста) — Для банка fallback на резервный ЦОД критичен.  — Для игры достаточно показать анимацию загрузки и продолжить сессию позже.

⚠️ Главное правило

Fallback не должен быть сложнее основной системы! Его задача — дать пользователю быстрое решение, даже если оно неидеально.

Пишите, если остались вопросы! 😉

Катим в прод