A model provider has an outage. What keeps the app working?
Why C is the answer
Fallback to another model, with circuit breaker logic
Falling back to another model behind a circuit breaker keeps the app answering during a provider outage.
In detail
- A fallback model keeps the app running.
- A circuit breaker stops the failing calls.
- Test the fallback path before you need it.
Use case
An illustrative scenario, not a real incident.
A model outage hits at peak. The circuit breaker stops calling it, and requests go to a fallback model.
See it in different ways
stateDiagram-v2 [*] --> Closed Closed --> Open: too many failures Open --> HalfOpen: after a wait HalfOpen --> Closed: test call works HalfOpen --> Open: test call fails
stateDiagram-v2 [*] --> Closed Closed --> Open: too many failures Open --> Fallback: use another model Open --> HalfOpen: after a wait HalfOpen --> Closed: test call succeeds HalfOpen --> Open: test call fails
stateDiagram-v2 state "Closed, normal" as s0 state "Open, use fallback" as s1 state "Half open, test" as s2 [*] --> s0 s0 --> s1: failures s1 --> s2: after a wait s2 --> s0: success
Key point: Fallbacks keep the app working.
Why the other options are wrong
- A. A retry loop with no delay that runs until the provider is back
- A tight retry loop adds load.
- B. A note on the status page that asks users to try again the next day
- A note does not keep the app working.
- D. Longer timeouts on each call so that requests wait for the provider
- Longer waits make the outage worse.