Circuit Breaker - Modern Application Development on AWS

Circuit Breaker

The circuit breaker pattern regulates the calls between microservices in your application. To respond to user requests, the microservices in your application make calls to each other. If Service A sends a call to Service B, but the return call from Service B is delayed or produces an error, then Service A returns an error to the user. If Service A retries the call instead of returning an error, it might provide a better user experience, but retries can produce extra load and long delays, and can end with an error returned to the user. Instead, Service A should recognize that Service B is down, and degrade gracefully, if possible.

Figure 7 – Example of a circuit breaker pattern with returned calls between microservices

In the circuit breaker pattern, when calls to other services take longer than expected or return errors, the circuit breaker keeps count of the incidences and changes to the open state if the count exceeds the limit you configure. When in the open state, the circuit breaker returns errors to the caller immediately, without calling downstream services. After a fixed amount of time has passed, the circuit breaker returns to a closed state, which allows calls to the downstream service to return to normal.

Figure 8 – Example of a circuit breaker pattern with errors returned immediately to the user

It was previously a best practice to implement circuit breakers using a library or framework in the service code, but now it is often handled in containerized microservices with sidecars. A sidecar is a separate helper container that is launched with the main container that exposes a core service. Envoy Proxy is one popular example of a sidecar. Though Envoy Proxy can be deployed on its own, it is often deployed as part of a service mesh. In this type of deployment, Envoy Proxy is the data plane and a tool such as AWS App Mesh or Istio is the control plane.