Design Patterns for Microservice Architecture – Circuit Breaker

In Microservice Architecture, where the Microservices communicates Synchronously, a Microservice usually calls other services to fulfill business requirements. Call to another service can fail due to transient faults (slow network connection, timeouts, or temporal unavailability). In such cases, retrying calls can solve fix the issue. However, if there is a severe issue (complete failure of the Microservice), then the Microservice is unavailable for a longer time. Retrying is pointless and wastes precious resources (thread is blocked, waste of CPU cycles) in such scenarios. Also, the failure of one service might lead to cascading failures throughout the application. In such scenarios, fail immediately is a better approach.

The Circuit Breaker pattern can come to the rescue for such use cases. A Microservice should request another Microservice via a proxy that works similarly to an Electrical Circuit Breaker. The proxy should count the number of recent failures that have occurred and use it to decide whether to allow the operation to proceed or simply return an exception immediately.

The Circuit Breaker can have the following three states:

• Closed: The Circuit Breaker routs requests to the Microservice and counts the number of failures in a given period of time. If the number of failures in a certain period of time exceeds a threshold, it then trips and goes to Open State.
• Open: Request from the Microservice fails immediately, and an exception is returned. After a timeout, the Circuit Breaker goes to a Half-Open state.
• Half-Open: Only a limited number of requests from the Microservice are allowed to pass through and invoke the operation. If these requests are successful, the circuit breaker goes to a Closed state. If any request fails, the Circuit Breaker goes to Open state.

Pros

• Improve the fault-tolerance and resilience of the Microservice Architecture.
• Stops the cascading of failure to other Microservices.

Cons

• Need sophisticated Exception handling.
• Logging and Monitoring.
• Should support manual reset.

When to use Circuit Breaker

• In tightly coupled Microservice Architecture where Microservices communicates Synchronously.
• If one Microservice has a dependency on multiple other Microservices.

When not to use Circuit Breaker

• Loosely coupled, event-driven Microservice Architecture.
• If a Microservice has no dependency on other Microservices.

Enabling Technology

API Gateway, Service Mesh, various Circuit Breaker Libraries (Hystrix, Reselience4J, Polly.