In software architecture, there’s a fascinating pattern called Circuit Breaker. As the electrical counterpart, the goal of this pattern is to completely prevent requests from hitting an ill service, lowering possible frustrations from clients submitting data that would, then, possibly be lost due to errors in the application. Normally, a Circuit Breaker is automatically activated, and orchestrated, when the error rate of such service hits a predetermined threshold.

With the possibility of losing information or, worst yet, having data being mishandled or corrupted, it’s best to have a part of the application virtually amputated than to deal with possible very bad aftermath. This gives developers a certain level of calm, although still being a critical event that needs fixing. But, at least, the “bleeding” is stopped.

Once things get fixed, the circuit breaker is turned off and requests can flow, once again, to the recovered service.

This pattern matches pretty well with another concept in the realm of continuous deployment: feature flags. If we use FF to roll out access to a service, we can make the circuit breaker turn off that FF, signalling that that service isn’t to be used at this time.