Modern-Day Architecture Design Patterns for Software Professionals

Circuit Breaker

Distributed systems should be designed by taking failures into consideration. These days the world has adopted microservices, and these services are mostly dependent on other remote services. These remote services could fail to respond in time due to various reasons like network, application load, etc. In most cases, implementing retries should be able to solve the issues.

But sometimes there may be major issues like service degradation or complete service failure in and of itself. It’s pointless to keep retrying in such cases. That’s where the Circuit Breaker pattern can be useful.

Circuit Breaker. Image by the author.

The above diagram showcases the implementation of the Circuit Breaker pattern, where when a Service 1 understands there are continuous failures/ timeouts when Service 2 is called, instead of retrying, Service 1 trips the calls to Service 2 and returns the fallback response.

There are popular open-source libraries, like Netflix’s Hystrix, that can be used to implement this pattern very easily.

If you’re using API gateways or sidecar proxies like Envoy, then this can be achieved at the proxy level itself.

Note: It’s very important that there’s sufficient logging and alerting implemented when the circuit is open in order to keep track of requests received during this time and that the operations team is aware of this.

You can also implement a circuit breaker with the half circuit open to continue to service clients with degraded service.

When to use this pattern

• When a service is dependent on another remote service, and it’s likely to fail in some scenarios
• When a service has a very high dependency (for example, master data services)

When not to use this pattern

• When you’re dealing with local dependencies — a Circuit Breaker might create overhead

from Hacker News https://ift.tt/33SXi7N