Retries amplify a long outage into a latency disaster; the breaker stops calling a sick provider entirely and probes for recovery on its own schedule.
Imagine the door to a busy restaurant is jammed. A retry policy is everyone standing in line wiggling the handle for 30 seconds before giving up and walking to the diner next door. A circuit breaker is the host stepping out and saying, the kitchen is down, please go to the diner; we will send a scout in five minutes to check if we are back open. The first version wastes everyone's time and crowds the doorway. The second version routes traffic instantly and sends one scout instead of a thousand. For LLM providers, the broken kitchen is a provider outage and the diner is your fallback model.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Retry policies and circuit breakers are often discussed in the same breath, which obscures how different their jobs are. Retries pick up dropped balls. Breakers walk off the field when the field is on fire. A team that has only the first has built half a resilience strategy and will discover it during their first multi-hour provider incident.
For LLM providers specifically, where outages tend to be wall-clock long, latency budgets are tight, and a fallback model is usually available, the breaker is not optional infrastructure. It is the difference between a graceful degradation and a self-inflicted latency cascade.
What retries do, and what they cannot do
A retry policy assumes the failure was bad luck and the next attempt has a fresh chance. For genuinely transient failures, a single network drop, a one-off 503, a brief overload, that assumption holds. Three retries with exponential backoff catch the vast majority of these and the user never sees the failure.
The assumption breaks the moment the failure is not bad luck. If the upstream provider is down for 30 minutes, every retry on every request burns through the backoff budget and still fails. The user-facing effect is brutal: p99 latency inherits the full retry budget (often 10 to 30 seconds with three attempts and backoff) on every request for the entire incident.
Three second-order effects pile on top. First, trace cardinality explodes because every failed attempt emits a span; your observability backend may itself start dropping. Second, the rate-limiter at the provider sees you hammering and may start shedding you specifically, slowing recovery for you compared to teams that backed off. Third, your fallback path (if you have one) only kicks in after the retry budget is exhausted, so latency stays bad until you have already wasted the budget.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- Portkey and LiteLLM proxy both ship per-route circuit breakers with rolling-window thresholds out of the box.
- Resilience4j in JVM services and PyBreaker in Python apps are the common in-process libraries when a gateway is not in the path.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you tune the failure-rate threshold and window size for a new service?
Start with a conservative baseline (50 percent over 30s with a 20-request floor), tune from real traffic patterns and historical incidents, alert on every state transition for the first month.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Relying on retries alone during a multi-hour provider outage and watching p99 latency balloon because every request burns its full retry budget before falling back.
60 second bullets to scan on the way to the call.
The three breaker states and what each one does
Why retries alone amplify a long outage instead of mitigating it
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.