Реалізація Fallback-логіки при недоступності AI-сервісу в мобільному додатку
OpenAI повертає 503 приблизно раз на кілька тижнів — в години піку або при інцидентах. Для мобільного додатку, де AI-асистент — частина core user flow, це означає білий екран або крах без fallback.
Рівні деградації
Правильний fallback — це не одна заглушка, а каскад деградації:
Рівень 1: Retry з backoff. Тимчасові помилки (429 Rate Limit, 503, timeout) — переспробуйте з exponential backoff. Три спроби: 1с, 3с, 9с окремо. Якщо все провалилося — перейти до рівня 2.
Рівень 2: Перемикання провайдера. Якщо основний OpenAI, fallback — Anthropic Claude API або Google Gemini. Відповіді різних провайдерів відрізняються стилем, але якість порівнянна для більшості задач. Зберегти ключі резервних провайдерів в конфігурацій сервера.
Рівень 3: Локальна модель. Для критичних флоу — мала локальна модель (Phi-3.5-mini через llama.cpp, ~2.2 ГБ). Нижча якість ніж GPT-4o, але працює offline. На iOS запускається через MLModel або llama.swift.
Рівень 4: Статичні відповіді. FAQs та часто задавані питання — з кешу або бази даних. Користувач отримує корисну відповідь, не знаючи про недоступність AI.
Реалізація Circuit Breaker
Паттерн Circuit Breaker запобігає каскадному навантаженню на деградуючий сервіс: відслідковує збої, открывает circuit після порогу, періодичні спроби відновлення.
UX при деградації
Користувачі не повинні бачити технічні помилки. На fallback на статичні відповіді — показати нормальний UI без позначення. На повну недоступність — «Асистент тимчасово недоступний, спробуйте через кілька хвилин» замість сирого Error 503.
Індикатор деградації корисний для внутрішньої аналітики: логуйте кожен fallback з рівнем та причиною.
Орієнтири за часом
Базовий retry з backoff — 1 день. Повний каскад з circuit breaker та двома провайдерами — 2–3 дні.