A 4-hour outage is ~5.6x your entire monthly error budget on a 99.9% SLA. You cannot ride it out. The design is a provider abstraction, a circuit breaker, and a tiered set of degraded modes, plus a clear line on what you cache versus what you replay.
Your product calls an external LLM API and you are on a 99.9% uptime SLA. The provider goes dark for 4 hours. Design the failover.
A 4-hour outage is ~5.6x your entire monthly error budget on a 99.9% SLA. You cannot ride it out. The design is a provider abstraction, a circuit breaker, and a tiered set of degraded modes, plus a clear line on what you cache versus what you replay.
Updated Aug 2026 · Grounded in real Forward Deployed Engineer interview loops and written to a senior-engineer editorial bar.
The first real signal is whether the candidate does the error-budget math: 99.9% is ~43 min/month, so 4 hours is roughly 5.6x the monthly budget and the question is not 'wait it out' but 'fail over or degrade'. Strong answers put every provider behind one interface, add a circuit breaker so you stop hammering a dead provider, and define a fallback ladder: secondary provider, then smaller/cheaper model, then cache, then queue, then a graceful 'reduced features' mode. The reserve probe is the consistency one: what do you cache (idempotent reads, embeddings) versus what must you queue and replay (writes, anything with side effects), and how do you avoid double-execution on replay. Watch for candidates who name a backup provider but never address prompt portability or output-format drift between providers.
No comments yet — be the first to share your approach.
