Resilient architectures with Circuit Breaker
The aspects of resilient architectures are comprehensive. In addition to some basic paradigms such as e.g. loose coupling, fallback and redundancy, some architectural patterns also represent important milestones on the rocky road to “resilient”. One of these patterns is Circuit Breaker. In this article we introduce the architecture pattern Circuit Breaker and discuss possible usage scenarios.
Resilient: a (very) short introduction
Today’s system landscapes consist of many components which communicate with each other. In this context, we often talk about distributed systems, however these appear as a unified system to users. Communication between components in a distributed system often results in errors. We speak of a resilient architecture when the system can deal with unexpected error situations and users don’t notice that an error has occurred. The word resilient also stands for robust. A resilient architecture is therefore also robustly withstands errors. Find more information about resilient design here.
Circuit Breaker as a fuse
A Circuit Breaker is a fuse. The concept is derived from the electrical fuse: When the current is too high, the fuse interrupts the electricity flow in order to protect the line from overload.
In the context of distributed systems, however, we don’t speak about current flows, but about dedicated communication flows between different communication of software The components of a dedicated system communicate with each other and exchange data. If errors occur during the communication, the functionality of the entire system can be impaired.
Imagine the following scenario: In a distributed system, the client uses the service on server function. The server is under load and is answering requests more and more slowly. The client ignores this and continues using the server the same may, until the server fails completely. If the service is a critical business process, it can no longer be used. This means that the client will no longer receive an response to a request and can no longer reproduce its expertise.
A Circuit Breaker can help avoid the scenario described above. The Circuit Breaker is switched between the client and the server and simply forwards the requests from the client to the server. The most important task of the circuit breaker is to monitor the communication by means of specific metrics (e.g. number of timeouts). If a communication threshold is exceeded (e.g. number of timeouts > set value), the Circuit Breaker will no longer forward the requests from the client to the server. The fuse therefore triggers and the server is protected from too high a load.
Fuse triggered: what now?
Once the fuse has triggered, the Circuit Breaker will no longer forward the requests from the client to the server, but will answer them itself.
The Circuit Breaker could, for example, deliver standard values, data from an older safety backup or also an error message. Essentially, it is about maintaining the expertise at least partially and saving resources. It might not be optimal, that the client is not receiving current data, however, this procedure is definitely better than not transmitting any data at all. It’s also not optimal that a client receives an error message. As the client doesn’t have to wait for a response, valuable resources are saved.
Other scenarios are conceivable, in which the Circuit Breaker transmits the requests to other servers, which are registered in the directory service, and are known to the Circuit Breaker.
In contrast to an electrical fuse, the Circuit Breaker should be able to independently reactivate the interrupted communication between the client and server. To do this, the Circuit Breaker forwards some requests from the client to the server and monitors the threshold based on the selected metrics. If this value is fallen below (e.g. numberTimeOuts < setValue), the Circuit Breaker will also forward the subsequent requests to the server. The communication is thus restored.
A reference implementation of the logic for activating the fuse and therefore the resumption of the communication can be found in a blog article by Martin Fowler.
In the context of a resilient architectures, the Circuit Breaker pattern plays an important role. This pattern helps to maintain part of the expertise and / or save resources in case of errors.
Author: Nicolai Zaidman
Blog - Technology & Innovation
Serverless Cloud Architecture – Secure data distribution with AWS S3, CloudFront and Lambda@Edge