I don't quite get option 1 cached response. If there is a cache in front of MS3, isn't it then the normal happy case? whether MS3 is up or down, we would hit the cache first and only hits MS3 if there is a cache miss. Further the cache typically only has a subset number of responses thus you won't be able to guarantee a successful call by going to the cache.
Can anyone explain why the cached response is a valid benefit of CB ? My key doubt is if the cached response was appropriate then why was the call made in the first place
Thanks for the good video. I have question. In case of service is not available how do we handle incoming request ? Do we keep any pending action timer for which we will be buffering request and later will process them or system will discard them directly by providing configured error response.
This is a poor explanation of circuit breaker pattern. The problem it solves is not the 5 times retry of service call to MS3. This same retry policy is also in effect on the other services in the chain, so when MS3 fails, MS2 will return an error and MS1 will retry calling MS2 for 5 times, and each call to MS2 will retry the call to MS3 5 times. Overall, MS3 will be called 25 times, MS2 will be called 5 times, so the failure of MS3 will cause a cascading exponential increase of calls, which will slow down the system. Circuit breaker prevents this from happening. If the retry policy is N times, and there are M services making chained calls, a faulting service at the end of the chain causes number of calls in the order of N to the power of M, this is for each call on the first service in the chain, which, when repeated, is enough to take the whole system down. Circuit breaker prevents these cascading failed calls from taking down the system.
