We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Graceful Degradation across a run of lessons, not one page. These 3 alone are about 68 minutes of step-by-step reading, every one with a quiz.
Provide reduced functionality instead of complete failure, fallbacks, feature flags, and cached responses.
Design systems that continue operating when components fail, redundancy, isolation, and graceful degradation.
Traditional web architecture where the server is the source of truth and offline is handled as a graceful degradation.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Graceful Degradationpay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Graceful Degradation
When parts of your system fail, give users a reduced experience instead of a broken one
Fault Tolerance
Design systems that continue operating when components fail, redundancy, isolation, and graceful degradation
Online-First Architecture
Traditional web architecture where the server is the source of truth and offline is handled as a graceful degradation
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.
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.
Failure Injection
Deliberately introducing faults (latency, errors, crashes) into a system to verify that resilience mechanisms work. A specific technique within chaos engineering.
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.
This page explains the idea. The "Graceful Degradation" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Graceful Degradation lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Graceful Degradation in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
