Circuit breaker design pattern: Difference between revisions

Revision as of 18:09, 28 November 2010

Latest revision as of 15:29, 14 April 2025

(86 intermediate revisions by 58 users not shown)

Line 1:

{{Short description|Software development pattern}}

{{Wikify|date=July 2010}}

The '''Circuit Breaker''' is a [[Design pattern (computer science)|design pattern]] commonly used in [[software development]] to improve system resilience and fault tolerance. Circuit breaker pattern can prevent [[cascading failure]]s particularly in [[Distributed computing|distributed systems]].<ref>{{Cite book |title=Machine Learning in Microservices Productionizing Microservices Architecture for Machine Learning Solutions |publisher=Packt Publishing |year=2023 |isbn=9781804612149}}</ref> In distributed systems, the Circuit Breaker pattern can be used to monitor service health and can detect failures dynamically. Unlike [[Timeout (computing)|timeout]]-based methods, which can lead to delayed error responses or the premature failure of healthy requests, the Circuit Breaker pattern can proactively identify unresponsive services and can prevent repeated attempts. This approach can enhance the user experience. <ref name=":1">{{Cite book |last=Richards |first=Mark |title=Microservices AntiPatterns and Pitfalls |publisher=O'Reilly}}</ref>

The circuit breaker pattern can be used in conjunction with other patterns, such as retry, fallback, and timeout, to enhance fault tolerance in systems. <ref>{{Cite book |title=Kubernetes Native Microservices with Quarkus and MicroProfile |publisher=Manning |year=2022 |isbn=9781638357155}}</ref>

'''Circuit breaker''' is a [[Design pattern (computer science)|design pattern]] in modern [[software development]].

==Challenges==

Circuit breaker is used to detect failures and encapsulates logic of preventing a failure to reoccur constantly (during maintenance, temporary external system failure or unexpected system difficulties).

According to Marc Brooker, circuit breakers can misinterpret a partial failure as total system failure and inadvertently bring down the entire system. In particular, sharded systems and cell-based architectures are vulnerable to this issue. A workaround is that the server indicates to the client which specific part is overloaded and the client uses a corresponding mini circuit breaker. However, this workaround can be complex and expensive.<ref>{{Cite book |title=Understanding Distributed Systems |isbn=9781838430214}}</ref><ref>{{Cite web |title=Will circuit breakers solve my problems? |url=https://brooker.co.za/blog/2022/02/16/circuit-breakers.html}}</ref>

==Common Uses==

== Different states of circuit breaker ==

Your application connects to a [[database]] 100 times per second and the database fails. You do not want to have the same error reoccur constantly. You also want to handle the error quickly and gracefully without waiting for [[TCP connection]] timeout.

* Closed

Generally Circuit Breaker can be used to check the availability of an external service. An external can be a database server or a web service used by the application.

* Open

* Half-open

=== Closed state ===

[[Circuit breaker]] detects failures and prevents the application from trying to perform the action that is doomed to fail (until its safe to retry).

[[File:Circuit Breaker -Closed state.png|thumb|Closed state]]

When everything is normal, the circuit breakers remain ''closed'', and all the requests pass through to the services. If the number of failures increases beyond the threshold, the circuit breaker trips and goes into an ''open'' state.

{{clear}}

==Implementation= Open state ===

[[File:Circuit Breaker -Openstate.png|thumb|Open state]]

In this state circuit breaker returns an error immediately without even invoking the services. The Circuit breakers move into the ''half-open'' state after a timeout period elapses. Usually, it will have a monitoring system where the timeout will be specified.

{{clear}}

=== Half-open state ===

The Circuit Breaker Design Pattern should be implemented asynchronously. The reason is to offload the logic to detect failures from the actual request.

[[File:Circuit Breaker -Half Open state.png|thumb|Half-open state]]

In this state, the circuit breaker allows a limited number of requests from the service to pass through and invoke the operation. If the requests are successful, then the circuit breaker will go to the ''closed'' state. However, if the requests continue to fail, then it goes back to ''open'' state.

==References==

This requires Circuit Breaker to use a persistent storage layer, e.g. a network cach such as [[Memcached]] or [[Redis]], or local cache (disk or memory based) to record the availability of a, to the application, external service.

{{reflist}}

==External links==

Circuit Breaker records the state of the external service on a given interval.

*[https://web.archive.org/web/20100625035128/http://artur.ejsmont.org/blog/PHP-Circuit-Breaker-initial-Zend-Framework-proposal Example of PHP implementation with diagrams]

*[https://code.4noobz.net/retry-pattern-with-polly/ Example of Retry Pattern with Polly using C#]

Before the external service is used from the application, the storage layer is queried to retrieve the current state.

*[http://www.lybecker.com/blog/2013/08/07/automatic-retry-and-circuit-breaker-made-easy/ Example of C# implementation from Anders Lybeckers using Polly]

*[https://www.nuget.org/packages/Polly/ Polly NuGet package]

==Performance Implication==

*[https://github.com/alexandrnikitin/CircuitBreaker.Net Example of C# implementation from Alexandr Nikitin]

*[https://pypi.org/project/pybreaker/ Implementation in Python]

While it's save to say that the benefits outweigh the consequences, implementing Circuit Breaker will of course affect the performance.

*[https://www.infoworld.com/article/2824163/stability-patterns-applied-in-a-restful-architecture.html Stability patterns applied in a RESTful architecture]

*[https://martinfowler.com/bliki/CircuitBreaker.html Martin Fowler Bliki]

By how much depends on the storage layer used and generally available resources. The largest factors in this regard are the type of cache, for example, disk-based vs. memory-based and local vs. network.

==Example Implementation==

===PHP===

The following is a [[Proof_of_concept|POC]] example implementation in PHP. The POC stores the status of a MySQL server into a shared memory cache ([[Alternative_PHP_Cache|APC]]).

==== Check ====

The following script could be run on a set interval through [[crontab]].

<source lang="php">

$db = mysql_connect('localhost','root','pass');

if ($db === false) {

apc_store('dbUp', 'up');

} else {

apc_store('dbUp', 'down');

@mysql_close($db);

}

</source>

====Usage in an application====

<source lang="php">

if (apc_fetch('dbUp') === 'down') {

echo "The database server is currently not available. Please try again in a minute.";

exit;

}

$db = mysql_connect('localhost', 'root', 'pass');

$res = mysql_db_query('database', 'SELECT * FROM table');

</source>

==Weblinks==

*[http://artur.ejsmont.org/blog/PHP-Circuit-Breaker-initial-Zend-Framework-proposal Example of PHP implementation with diagrams]

[[Category:Software design patterns]]