Unveiling the Layers: Delving into the Sitecore Tech Stack: Sitecore xConnect Circuit Breaker

Have you heard of Circuit Breaker design pattern? have you heard of configuring Circuit break for Sitecore xConnect? no, then this article is for you, I've been reviewing sitecore log files on my local Commerce environment and accidently found error messages related to Circuit Breaker while seeing xConnect errors caused by my xConnect instance had wrong connection strings info, I got interested and wanted to understand what is it and when it was introduced?! keep reading! :)

Recently while reviewing sitecore log files I ran into an error log that mention circuit breaker and here is how it looks like:

I got interested and wanted to know more about, so I looked into it, so starting from the definition:

Circuit breaker is a design pattern used in software development. It is used to detect failures and encapsulates the logic of preventing a failure from constantly recurring, during maintenance, temporary external system failure or unexpected system difficulties.

So, In short the idea of software circuit breaker is taken from the electrical switch which is designed to protect electrical equipment from excess current, Its a design pattern that is important to implement in a service oriented architecture, by which we can prevent overwhelming a service or a provider with requests while this service/provider having issues, the idea basically depends on three states as following:

Closed: means the Circuit Breaker is in connected state, and requests are made to the service provider.
Half-Open: means the Circuit Breaker is in a test state, meaning, the Circuit breaker will re-establish the connection to the service provider BUT ready to switch to open state the minute the service provider dose not respond.
Open: means the Circuit Breaker shut down the requests to the service provider.

You probably run into the same issue I had where you can see too many errors related to xConnect or xDB connection or various errors in your CM or CD logs, overwhelming your logs in a way that prevents you from accurate analysis, also you may have seen a performance issue on your servers caused by the too many failing requests going into a broken xConnect instance, right?! so why not we use the Circuit Breaker pattern as the xConnect acts as an external service which we should assume it may go down and we should do something to prevent /handle that.

While looking into the release notes, I found that this was actually added by Sitecore in Sitecore 10 initial release, here is the release link, its really a great feature that is so important to have specially in the xConnect scenario.

Sitecore implemtation of this design pattern is using the Polly Circuit Breaker library and has added a Polly.IAsyncPolicy<HttpResponseMessage> type field to to the Sitecore.Xdb.Common.Web.CommonWebApiClient<TRoutes> class. This allows you to do a dependency injection of the Polly.CircuitBreaker class, which is an implementation of Polly.IAsyncPolicy.

There are also different ways for enabling Circuit Breaker for xConnect including:

Enable a CircuitBreaker configuration by patch file for Content Management requests.
Enable a CircuitBreakerInfos configuration by patch file for requests from roles other than Content Management.
Enable a CircuitBreaker factory by constructor parameter for a more customizable solution.
Enable a CircuitBreaker factory by patch file for a more customizable and flexible solution.

You can find much more information in Sitecore documentation, please see the resources/further reading section at the end for more, happy reading!!