Circuit Breaker Pattern Overview

The microservice Circuit Breaker pattern is an automated switch capable of detecting extremely long response times or failures when calling remote services or resources. The circuit breaker pattern proxies or encapsulates service A making a call to remote service or resource B. When error rates or response times exceed a desired threshold, the breaker “pops” and returns an appropriate error or message regarding the interface status. Doing so allows calls to complete more quickly, without tying up TCP ports or waiting for traditional timeouts. Ideally the breaker is “healing” and senses the recovery of B thereby resetting itself.

Disambiguation

The circuit breaker analogy works well in that it protects a given circuit for calls in series. Unfortunately, it misses the true analogy of tripping to protect the propagation of a failure to other components on other circuits. We often use the term circuit breaker in our practice to refer to either the technique of fault isolation or the microservice pattern of handling service to service faults. In this article, we use the circuit breaker consistent with the microservice meaning.

Microservice Circuit Breaker Overview

Problems the Circuit Breaker Fixes

Generally speaking, we consider service to service calls to be an anti-pattern to be avoided whenever possible due to the multiplicative effect of failure and the resulting lowering of availability. There are, however, sometimes that you just can't get around making distant calls. Examples are:

  1. Resource (e.g. database) Calls: Necessary to interact with ACID or NoSQL Solutions.

  2. Third Party Integrations: Necessary to interact with any third party. While we prefer these to be asynchronous, sometimes they must be synchronous.

In these cases, it makes sense to add a component, such as the circuit breaker, to help make the service more resilient. While the breaker won't necessarily increase the availability of the service in question, it may help reduce other secondary and tertiary problems such as the inability to access a service for troubleshooting or restoration upon failure.

Principles to Apply

  1. Avoid the need for circuit breakers whenever possible by treating calls in series as an anti-pattern.

  2. When calls must be made in series, attempt to use an asynchronous and non-blocking approach.

  3. Use the circuit breaker to help speed recovery and identification of failure, and free up communication sockets more quickly.

When to use the Circuit Breaker Pattern

  • Useful for calls to resources such as databases (ACID or BASE).

  • Useful for third party synchronous calls over any distance.

  • When internal synchronous calls can't otherwise be avoided architecturally, useful for service to service calls under your control.

Key Takeaways

The circuit breaker won't fix availability problems resulting from a failed service or resource. It will make the effects of that failure more rapid which will hopefully:

  • Free up communication resources (like TCP sockets) and keep them from backing up.

  • Help keep shared upstream components (e.g. load balancers and firewalls) from similarly backing up and failing.

  • Help keep the failed component or service accessible for more rapid troubleshooting and alerting.

  • Always ensure to have alerts fired on breaker open situations to help aid in faster time to detect (TTD).

AKF Partners has helped hundreds of companies implement new microservice architectures and migrate existing monolithic products to microservice architectures. Give us a call – we can help!