Graceful Degradation
A strategy where a system continues to function with reduced capability when a component fails, instead of crashing entirely. Show cached results when the database is down.
What is Graceful Degradation?
In short
Graceful degradation is a design strategy where a system keeps serving users with reduced functionality when a dependency fails, instead of returning errors or crashing entirely. For example, a product page can still load with cached prices and a "recommendations unavailable" placeholder when the recommendation service is down.
What It Is
Graceful degradation is the practice of letting non-essential parts of a system fail without taking down the whole experience. When a component goes offline, slows down, or returns errors, the system falls back to a simpler but still useful response rather than showing a blank screen or a 500 error.
The key idea is ranking features by importance. The core path, browsing products, reading an article, sending a message, stays up. The secondary features, personalized recommendations, live view counts, related links, get switched off or replaced with a static placeholder when their backing service is unhealthy.
It is the opposite of an all-or-nothing failure. A system without graceful degradation treats every dependency as required, so one slow database or one dead microservice cascades into a full outage. A system with it draws a line between must-have and nice-to-have, and protects the must-have.
How It Works Under the Hood
The first building block is a timeout and a fallback. Every call to a dependency gets a deadline, often 100ms to 2s depending on the call. If the dependency does not answer in time, the calling code does not wait forever. It catches the timeout and returns a default value: an empty list, a cached copy, or a feature-disabled flag.
The second building block is the circuit breaker. After a dependency fails a set number of times, say 50 percent of requests in a 10 second window, the breaker opens and the system stops calling that dependency at all for a cooldown period. During that window every request goes straight to the fallback, which stops the failing service from being hammered and stops user requests from piling up behind slow calls.
Behind both of these sits a cache and a set of sensible defaults. When the live data source is unavailable, the system serves the last good value it stored, or a generic default. Feature flags let operators turn expensive or fragile features off by hand during an incident, which is the manual version of the same idea.
When To Use It and the Trade-Offs
Use graceful degradation on any user-facing path where partial results beat no results. Read-heavy pages, dashboards, feeds, and search results are good candidates because a slightly stale or trimmed answer is still useful. It is most valuable for the dependencies you do not fully control, such as a third-party API, a recommendation model, or an analytics service.
Be careful where correctness is non-negotiable. You should not silently degrade a payment authorization, a balance check, or an inventory decrement by serving stale data, because that produces double charges or oversold stock. For those flows the right answer is to fail loudly and stop, not to fall back to a guess.
The cost is complexity and testing burden. Every fallback is a second code path that has to be written, reviewed, and exercised. Fallbacks that are never tested tend to be broken when you finally need them, so teams run game days and chaos experiments that deliberately kill dependencies to confirm the degraded mode actually works.
A Concrete Real-World Example
Picture an e-commerce product page that pulls from four services: catalog, pricing, recommendations, and reviews. The catalog and pricing are core, so the page cannot render without them. Recommendations and reviews are secondary.
On a normal request all four respond and the page is complete. Now the recommendations service starts timing out. The page sets a 300ms deadline on that call, the call exceeds it, the code catches the timeout, and the page renders with the recommendations block hidden or replaced by a generic best sellers list pulled from cache. The shopper can still see the product, the price, and the buy button, and can still check out.
Without this design, the same recommendations timeout would block the whole page render, the user would see a spinner or an error, and a service that has nothing to do with buying would have cost the company a sale.
Where it is used in production
Netflix
If its personalization service is unhealthy the homepage falls back to non-personalized rows of popular titles, and the Hystrix library it open-sourced popularized circuit breakers and fallbacks.
Amazon
Product pages render the core item and price even when secondary widgets like recommendations or recently viewed are slow, hiding the failing block rather than failing the page.
Google Search
When a backend shard is slow Google returns the results it has within the time budget rather than waiting, trading a small amount of completeness for a fast answer.
Cloudflare
Workers and its CDN can serve stale-while-revalidate cached content when an origin server is down, keeping sites readable through origin outages.
Frequently asked questions
- What is the difference between graceful degradation and fault tolerance?
- Fault tolerance aims to keep full functionality despite a failure, usually through redundancy like a standby replica taking over with no visible change. Graceful degradation accepts reduced functionality: the user still gets a working but trimmed experience. They are complementary, and a real system uses both.
- How is graceful degradation different from a circuit breaker?
- A circuit breaker is one mechanism, it stops calling a failing dependency after repeated errors. Graceful degradation is the broader strategy of what the system does instead, such as serving cached data, a default, or hiding a feature. The circuit breaker decides when to fall back, the degradation logic decides what to fall back to.
- Does graceful degradation hurt data accuracy?
- It can, because fallbacks often serve cached or default data that may be stale. That is an acceptable trade for non-critical reads like recommendations or view counts, but it is dangerous for money, inventory, or authorization flows, where you should fail closed and stop rather than degrade.
- How do you test that degraded mode actually works?
- Run chaos experiments and game days that deliberately kill or slow a dependency in a controlled environment, then confirm the fallback path fires and the user-facing core still works. Fallbacks that are never exercised are usually broken by the time a real incident hits.
- What timeout should a fallback use?
- Set it just above the dependency's normal p99 latency so healthy calls succeed but slow calls are cut off quickly. Common values range from 100ms for fast internal calls to 1 to 2 seconds for external APIs. The goal is to fail fast enough that one slow dependency does not exhaust your request threads.
Learn Graceful Degradation hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Graceful Degradation as part of a larger topic.
Reliability for Stochastic Systems: Error Budgets for Probabilistic Output
Uptime cannot measure a system that answers wrong while healthy. Define a quality SLO, run an error budget on the pass rate, and degrade to honest fallbacks.
ml-advanced · llm genai ops
Graceful Degradation
When parts of your system fail, give users a reduced experience instead of a broken one
intermediate · microservices architecture
Fault Tolerance
Design systems that continue operating when components fail, redundancy, isolation, and graceful degradation
advanced · reliability resilience
Online-First Architecture
Traditional web architecture where the server is the source of truth and offline is handled as a graceful degradation
intermediate · web content delivery
Production RAG and LLM Systems: Running It, Not Just Building It
The operations view of a live RAG plus LLM service: serving, latency budgets, cost per query, caching, index freshness, autoscaling, graceful degradation, retrieval monitoring, guardrails, and SLOs.
ml-foundation · core
See also
Related glossary terms you might want to look up next.
Circuit Breaker
A pattern that stops calling a failing service after repeated failures, preventing cascade failures. Like an electrical circuit breaker that cuts power to prevent fires.
Fault Tolerance
A system's ability to keep operating correctly even when some of its components fail. Achieved through redundancy, replication, and graceful degradation.
Bulkhead
A pattern that isolates different parts of a system so a failure in one part doesn't sink the whole ship. Named after the compartments in a ship's hull.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.