let's suppose , My service A is making requests to service B and the minimum request per second is 10 to check fail occurrence. now lets say I am experiencing failure with 300 request per second from A to B (more than 50% requests have been dropped, though first 149 request is successful and next 151 request has been failed) which was operating fine in 149 requests per second. Now is this really a good idea just to break the connection and make 10 request per second after some interval to check if the service B is ok? as it will be ok for first 10 requests but will fail every time after number 149th request. Could this circuit breaker decrease request per second in binary approach (300 request fails so lets check with 150, then 75 or so) rather than just immediate cut and check with 10 requests per second after some interval (and if this 10 request is successful then will I immediately make 300 due requests that are coming or I will follow sequential approach to 300th ? ). could this approach give better performance as now I can come to know by some learning mechanism how much it really can handle and make the best use of it's resource rather than just abandon it just because it can't handle so much load though it can handle a number of load. yeah I am only considering the case "server load" but this scenario just came across my mind and wanna know about this scenario performance issue of this design pattern
I have found the answer after some searching as I had no previous knowledge about "Circuit Breaker Pattern". The thing is, in here - "Every time the call succeeds, we reset the state to as it was in the beginning" so in my given case or whatever it will perform best with an optimized solution. So, after succeeding the 149th request it will actually set its counter to Zero and then 50% failure rate will come to a point, and then after 10 subsequent failed requests (100% failure rate) it will break the circuit for any "next", not previous succeded request-response, so let's say it will just handle 149 requests for forwarding and send fallback for any next requests. You can include that line for readers like me who had no previous knowledge and thanks for the great article though..!
Hi Fuji, extremely sorry for the late reply. Was stuck! :(
Thanks for your question. A Circuit breaker can be of two types - a) counter-based b)sliding window-based.
A counter-based Circuit breaker will monitor X amount of requests. If you see the image in the article, the circuit breaker will start from the closed state. Then it will monitor the requests. If you configured that out of 10 requests if 5 fails you'll trip the circuit, then the breaker will monitor 10 requests and track how many are successful. At first, it will monitor at least 10 requests. After the 10th request, it will take the decision. From your example, say, the first 149 requests are successful. Nothing breaks. After that, your requests start to fail. If out of the next 10 requests 5 fails, the circuit breaker will trip the circuit and the state will be the open state. As I explained in the state transition paragraph in the above article, the circuit breaker will have a cool-down period until which it will wait before making another decision. You can set the cool-down period. After that, the circuit breaker will go to the half-open state as I mentioned in the article. Here, the circuit breaker will let some requests pass through and many of them will be not. And in the half-open state, if the circuit breaker sees that out of the 10 requests that it passed through 5 failed then it will again switch to the open state. Otherwise, it will switch to the closed state. The whole 151 requests will not be used to trip the circuit.
Hope it helps. If you have questions, please do comment. I liked your question. And again, sorry for the late response.
yeah, so the counter is resetting (starting to monitor) after every success call as I started counting after the first failure? but then after 3 consecutive fails and then 1 success call will again reset the state -_- or the concept is I just monitor (without resetting) consecutive 10 requests then reset and again monitor 10 consecutive requests and again?
and as you said when after failing over 50% request handling (the first 149 was good then consecutive 6 fails) during the cool down period or half-open state, is the server serving that capable 149 requests and not making another call (hold) within short time or it is now not handling any requests? (um confused here) as from our trivial knowledge we know circuit breaker as breaking the full circuit while overload but here we can code to serve the capable 149 request and hold for any new requst (cool down)?
Thanx a lot for the reply <3
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
let's suppose , My service A is making requests to service B and the minimum request per second is 10 to check fail occurrence. now lets say I am experiencing failure with 300 request per second from A to B (more than 50% requests have been dropped, though first 149 request is successful and next 151 request has been failed) which was operating fine in 149 requests per second. Now is this really a good idea just to break the connection and make 10 request per second after some interval to check if the service B is ok? as it will be ok for first 10 requests but will fail every time after number 149th request. Could this circuit breaker decrease request per second in binary approach (300 request fails so lets check with 150, then 75 or so) rather than just immediate cut and check with 10 requests per second after some interval (and if this 10 request is successful then will I immediately make 300 due requests that are coming or I will follow sequential approach to 300th ? ). could this approach give better performance as now I can come to know by some learning mechanism how much it really can handle and make the best use of it's resource rather than just abandon it just because it can't handle so much load though it can handle a number of load. yeah I am only considering the case "server load" but this scenario just came across my mind and wanna know about this scenario performance issue of this design pattern
I have found the answer after some searching as I had no previous knowledge about "Circuit Breaker Pattern". The thing is, in here - "Every time the call succeeds, we reset the state to as it was in the beginning" so in my given case or whatever it will perform best with an optimized solution. So, after succeeding the 149th request it will actually set its counter to Zero and then 50% failure rate will come to a point, and then after 10 subsequent failed requests (100% failure rate) it will break the circuit for any "next", not previous succeded request-response, so let's say it will just handle 149 requests for forwarding and send fallback for any next requests. You can include that line for readers like me who had no previous knowledge and thanks for the great article though..!
Hi Fuji, extremely sorry for the late reply. Was stuck! :(
Thanks for your question. A Circuit breaker can be of two types - a) counter-based b)sliding window-based.
A counter-based Circuit breaker will monitor X amount of requests. If you see the image in the article, the circuit breaker will start from the closed state. Then it will monitor the requests. If you configured that out of 10 requests if 5 fails you'll trip the circuit, then the breaker will monitor 10 requests and track how many are successful. At first, it will monitor at least 10 requests. After the 10th request, it will take the decision. From your example, say, the first 149 requests are successful. Nothing breaks. After that, your requests start to fail. If out of the next 10 requests 5 fails, the circuit breaker will trip the circuit and the state will be the open state. As I explained in the state transition paragraph in the above article, the circuit breaker will have a cool-down period until which it will wait before making another decision. You can set the cool-down period. After that, the circuit breaker will go to the half-open state as I mentioned in the article. Here, the circuit breaker will let some requests pass through and many of them will be not. And in the half-open state, if the circuit breaker sees that out of the 10 requests that it passed through 5 failed then it will again switch to the open state. Otherwise, it will switch to the closed state. The whole 151 requests will not be used to trip the circuit.
Hope it helps. If you have questions, please do comment. I liked your question. And again, sorry for the late response.
yeah, so the counter is resetting (starting to monitor) after every success call as I started counting after the first failure? but then after 3 consecutive fails and then 1 success call will again reset the state -_- or the concept is I just monitor (without resetting) consecutive 10 requests then reset and again monitor 10 consecutive requests and again?
and as you said when after failing over 50% request handling (the first 149 was good then consecutive 6 fails) during the cool down period or half-open state, is the server serving that capable 149 requests and not making another call (hold) within short time or it is now not handling any requests? (um confused here) as from our trivial knowledge we know circuit breaker as breaking the full circuit while overload but here we can code to serve the capable 149 request and hold for any new requst (cool down)?
Thanx a lot for the reply <3