As the name suggests, this pattern is named like this because it comes from the electronic circuit context.

It sounds familiar, doesn't it?

The purpose of the circuit breaker pattern is the same as bulkheads, but with a different approach. Here, too, a service calling another service that is not responding or is very slow might decrease the performance of the overall system.

There is also another reason to implement the circuit breaker, which is to avoid having to keep on calling a service that you already know is broken or not reachable.

Suppose service A is calling service B, and service B is down—service A should prevent such integration and respond with a timeout error or cached data. Electronically speaking, this is the open state in the circuit, that is, no more connection between the two points.

The circuit breaker implementation should poll service B periodically to check its healthiness. Once service B is up again, the circuit breaker should reset the flow, having service A calling service B once more. Electronically speaking, this is the close state in the circuit.

The way the circuit breaker checks the integration point depends on the use case. It might suspend service B after a certain number of invocations go wrong. If so, it's best to wait and retry.

The most well-known implementation of the circuit breaker is given by Netflix Hystrix. However, this library has no more active development and is in maintenance mode. Of course, there are alternatives to Netflix Hystrix, such as Resilience4j, Sentinel, and Istio.

The latter is the one that's used by OpenShift., the PaaS supported by Red Hat, we will be describing it in the next section.