We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Open Netflix. The homepage shows personalized recommendations, trending shows, "because you watched," and your watchlist. Behind the scenes, this page calls at least 10 different : recommendation engine, user profile, trending algorithm, watch history, artwork service, A/B testing, and more.
What happens when the recommendation engine goes down? Two options:
Option A: Show an error page. "Something went wrong. Try again later." The user leaves and watches YouTube instead.
Option B: Show the homepage with generic popular titles instead of personalized recommendations. The user doesn't even notice anything is wrong. They browse, pick a show, and watch it.
Netflix chose Option B. Their entire architecture is built around the idea that partial functionality is infinitely better than no functionality. This principle is called graceful degradation: when a component fails, the system continues working with reduced capability rather than failing completely.
In 2012, Netflix published their approach: every service call has a fallback defined before the first line of code is written. Their Hystrix library (now Resilience4j) enforced this at the framework level. You could not call a downstream service without defining what happens when it's unavailable.
Your users would rather see an imperfect page than an error page. Every single time.
Graceful degradation means defining what happens when each dependency fails, before it actually fails.
| Strategy | How It Works | Example |
|---|---|---|
| Static Fallback | Return a pre-computed or default value | Show "Popular in your region" instead of personalized recommendations |
| Cached Fallback | Return the last known good response | Show yesterday's trending list when the trending service is down |
| Feature Removal | Hide the broken feature entirely | Remove the "Similar products" section when the similarity service fails |
| Simplified Response | Return less data than usual | Show product names and prices but skip reviews when the review service is down |
| Queue for Later | Accept the request now, process when service recovers | Accept the order, process payment when payment service comes back |
The key decision for each dependency: What is the minimum viable experience if this dependency is unavailable? If you can't answer that question for every service your system depends on, you don't have graceful degradation. You have optimistic hoping.
Amazon answers this question in a design document before any service is built. Their product managers classify every dependency as P0 (page cannot render without it), P1 (page is noticeably worse without it), or P2 (user won't notice it's missing). Only P0 dependencies block the page. P1 and P2 degrade.