We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
5 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Reliability Resilience
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 Reliability Resilience
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”
In 2011, Netflix had a problem that no amount of horizontal scaling could fix. Their recommendations service slowed down. Not crashed. Just got slow. Response times climbed from 50 ms to 5 seconds.
Here is what happened next. Every page rendering thread on the Netflix home page called the recommendations service. Each thread sat there waiting 5 seconds for a response. Tomcat's default thread pool is 200 threads. At 40 requests per second, each holding a thread for the full 5 seconds, 200 threads are in flight after 5 seconds and the pool is gone. Now every endpoint on the home page was unresponsive, not just recommendations. Profile, recently watched, trending, search. Everything. Because they all shared the same thread pool, and that pool was full of threads blocked on one slow service.
The system looked completely dead. But the actual root cause was a single dependency that was slow, not even down. This cascading failure pattern is what led Netflix to build Hystrix, the library that defined how the industry thinks about resilience. Hystrix was deprecated in 2018, but the pattern it established lives on in Resilience4j, Polly, Sentinel, and gobreaker.
A is a state machine that sits between your code and every downstream call. It tracks recent error rates and decides: should I let this call through, or fail it immediately?
| State | What Happens | Duration |
|---|---|---|
| Closed | Requests pass through normally. Errors are counted in a sliding window. | Until error rate exceeds threshold. |
| Open | All requests fail immediately with a fallback. Downstream gets zero traffic. | Configurable timeout (60 seconds default in Resilience4j). |
| Half-Open | A small number of test requests pass through. | Until test calls succeed or fail. |
The value proposition is simple: a broken downstream causes a 5 second timeout per request. A tripped circuit breaker causes a 1 millisecond failure. That difference, 5000x faster failure, is what prevents thread pool saturation and cascade failures.
But a circuit breaker without a fallback is only half the solution. Failing fast is better than failing slow, but users still see an error. The real win is when the fallback returns something useful: cached data, default recommendations, an empty list. Netflix's canonical example: when personalized recommendations fail, return the top 10 most popular items. Users still see recommendations. They just are not personalized.