# Design Patterns for Microservices — Circuit Breaker Pattern ![rw-book-cover](https://miro.medium.com/max/640/1*e3Nbt6-XZo03VWvU376TKQ.jpeg) URL:: https://medium.com/nerd-for-tech/design-patterns-for-microservices-circuit-breaker-pattern-ba402a45aac2 Author:: Nisal Pubudu ## Highlights > The Circuit Breaker pattern is a popular design pattern used in Microservices Architecture, that falls under the Sustainable Design Patterns category. In Microservices architecture, a service usually calls other services to retrieve data, and there is the chance that the downstream service may be down. It may be cause by slow network connection, timeouts, or temporal unavailability. Therefore, retrying calls can solve the issue. However, if there is a severe issue on a particular microservice, then it will be unavailable for a longer time. In such case, the request will be continuously sent to that service, since the client doesn’t have any knowledge about a particular service being down. As a result, the network resources will be exhausted with low performance and bad user experience. Also, the failure of one service might lead to **Cascading failures** throughout the application. ([View Highlight](https://read.readwise.io/read/01fdaxem89jq68ygw8tqjrg5p3)) > In Microservices architecture, a service usually calls other services to retrieve data, and there is the chance that the downstream service may be down. It may be cause by slow network connection, timeouts, or temporal unavailability. Therefore, retrying calls can solve the issue. However, if there is a severe issue on a particular microservice, then it will be unavailable for a longer time. In such case, the request will be continuously sent to that service, since the client doesn’t have any knowledge about a particular service being down. As a result, the network resources will be exhausted with low performance and bad user experience. Also, the failure of one service might lead to **Cascading failures** throughout the application. ([View Highlight](https://read.readwise.io/read/01fdaxdfmp5y8ad0wpaf8kmzd8)) > Therefore, you can use the Circuit Breaker Design Pattern to overcome this problem. With the help of this pattern, the client will invoke a remote service through a proxy. This proxy will basically behave as an electrical circuit breaker. So, when the number of failures crosses the threshold number, the circuit breaker trips for a particular time period. Then, all the attempts to invoke the remote service will fail within this timeout period. After the timeout expires, the circuit breaker allows a limited number of test requests to pass through it. If those requests succeed, the circuit breaker resumes back to the normal operation. ([View Highlight](https://read.readwise.io/read/01fdaxgwpfpvm7qv19kyde3mpg)) > **Closed state** > In this state, the Circuit Breaker routs the requests to the Microservice and counts the number of failures in each period of time. That means it work without any failures. But if the number of failures in a certain period of time exceeds a threshold, the circuit will trip and will move to an “Open” state. > ![](https://miro.medium.com/max/10000/1*RLDpD-OKWRAbRog6D5QiRA.png?q=20000000) > Representing Closed state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhbvm5bzdrw0s1gn76pph)) > **Open state** > When Circuit breaker moves to the “Open” state, requests from the Microservices will fail immediately, and an exception will be returned. However, after a timeout, the Circuit Breaker will go to the “Half-Open” state. > ![](https://miro.medium.com/max/10000/1*_90KuTuqakzeOT50dMaMDA.png?q=20000000) > Representing Open state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhgzt0thxvp6cqp461jjm)) > Half-Open state > In this state, the Circuit Breaker allows only a limited number of requests from the Microservice, to pass through and invoke the operation. If these requests are successful, the Circuit Breaker will go back to the “Closed” state. However, if any request fails again, it goes back to the “Open” state. > ![](https://miro.medium.com/max/10000/1*Se9BeQ4TxkA7GDdeZssHZg.png?q=20000000) > Representing Half-open state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhqjgvj3xpmzt9g4n4jan)) > Why Availability Matters in Microservices Architecture ([View Highlight](https://read.readwise.io/read/01fdaxjzc658py6vfs6y05v48w)) - Note: More services means more chances of a single source of downtime to affect multiple services, and each service adds to the downtime for SLA purposes. --- Title: Design Patterns for Microservices — Circuit Breaker Pattern Author: Nisal Pubudu Tags: readwise, articles date: 2024-01-30 --- # Design Patterns for Microservices — Circuit Breaker Pattern ![rw-book-cover](https://miro.medium.com/max/640/1*e3Nbt6-XZo03VWvU376TKQ.jpeg) URL:: https://medium.com/nerd-for-tech/design-patterns-for-microservices-circuit-breaker-pattern-ba402a45aac2 Author:: Nisal Pubudu ## AI-Generated Summary medium. com needs to review the security of your connection before proceeding. ## Highlights > The Circuit Breaker pattern is a popular design pattern used in Microservices Architecture, that falls under the Sustainable Design Patterns category. In Microservices architecture, a service usually calls other services to retrieve data, and there is the chance that the downstream service may be down. It may be cause by slow network connection, timeouts, or temporal unavailability. Therefore, retrying calls can solve the issue. However, if there is a severe issue on a particular microservice, then it will be unavailable for a longer time. In such case, the request will be continuously sent to that service, since the client doesn’t have any knowledge about a particular service being down. As a result, the network resources will be exhausted with low performance and bad user experience. Also, the failure of one service might lead to **Cascading failures** throughout the application. ([View Highlight](https://read.readwise.io/read/01fdaxem89jq68ygw8tqjrg5p3)) > In Microservices architecture, a service usually calls other services to retrieve data, and there is the chance that the downstream service may be down. It may be cause by slow network connection, timeouts, or temporal unavailability. Therefore, retrying calls can solve the issue. However, if there is a severe issue on a particular microservice, then it will be unavailable for a longer time. In such case, the request will be continuously sent to that service, since the client doesn’t have any knowledge about a particular service being down. As a result, the network resources will be exhausted with low performance and bad user experience. Also, the failure of one service might lead to **Cascading failures** throughout the application. ([View Highlight](https://read.readwise.io/read/01fdaxdfmp5y8ad0wpaf8kmzd8)) > Therefore, you can use the Circuit Breaker Design Pattern to overcome this problem. With the help of this pattern, the client will invoke a remote service through a proxy. This proxy will basically behave as an electrical circuit breaker. So, when the number of failures crosses the threshold number, the circuit breaker trips for a particular time period. Then, all the attempts to invoke the remote service will fail within this timeout period. After the timeout expires, the circuit breaker allows a limited number of test requests to pass through it. If those requests succeed, the circuit breaker resumes back to the normal operation. ([View Highlight](https://read.readwise.io/read/01fdaxgwpfpvm7qv19kyde3mpg)) > **Closed state** > In this state, the Circuit Breaker routs the requests to the Microservice and counts the number of failures in each period of time. That means it work without any failures. But if the number of failures in a certain period of time exceeds a threshold, the circuit will trip and will move to an “Open” state. > ![](https://miro.medium.com/max/10000/1*RLDpD-OKWRAbRog6D5QiRA.png?q=20000000) > Representing Closed state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhbvm5bzdrw0s1gn76pph)) > **Open state** > When Circuit breaker moves to the “Open” state, requests from the Microservices will fail immediately, and an exception will be returned. However, after a timeout, the Circuit Breaker will go to the “Half-Open” state. > ![](https://miro.medium.com/max/10000/1*_90KuTuqakzeOT50dMaMDA.png?q=20000000) > Representing Open state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhgzt0thxvp6cqp461jjm)) > Half-Open state > In this state, the Circuit Breaker allows only a limited number of requests from the Microservice, to pass through and invoke the operation. If these requests are successful, the Circuit Breaker will go back to the “Closed” state. However, if any request fails again, it goes back to the “Open” state. > ![](https://miro.medium.com/max/10000/1*Se9BeQ4TxkA7GDdeZssHZg.png?q=20000000) > Representing Half-open state (blogs.halodoc.io) ([View Highlight](https://read.readwise.io/read/01fdaxhqjgvj3xpmzt9g4n4jan)) > Why Availability Matters in Microservices Architecture ([View Highlight](https://read.readwise.io/read/01fdaxjzc658py6vfs6y05v48w)) Note: More services means more chances of a single source of downtime to affect multiple services, and each service adds to the downtime for SLA purposes.