Circuit Breaker in the time of Serverless

Circuit Breaker in the time of Serverless

Circuit Breaker, this lovely boy

What Circuit Breaker exactly is? Well, when you start developing loosely coupled applications your willing is increase availability, resiliency and why not start implementing chaos engineering. Since one of these can fail, you just don’t want other services wait more than it’s necessary, so you can develop a circuit breaker to “open the circuit” and promptly response when a service is unavailable.


Well we know that if you’re reading and you had no microservices development experience it might sounds weird, but yes we want to “fail fast” in case of a failure. This is possible thanks to microservice infrastructure that keeps working even if a microservice fail, that’s why we want it to response fast when it’s not working as we expected, so other services can go ahead without having to wait for it.

Cool right? Yeah, we know. All good when we talk about “usual” microservices environment such as Kubernetes, Swarm or ECS, that are based on hosts, so an amount of fixed costs are planned. But what if I’m using Serverless Computing?

…in the time of Serverless

Problem starts to get tricky if you’re about to develop a service in a Serverless environment. Serverless means near-to-zero costs for IDLE, but this worths also for temporary unavailable service, or at least it should. So how to optimize the Circuit Breakin’ paradigm for Serverless?

Easy, leveraging on Serverless Framework. Since it can manage the whole stack, including Cloudformation template, it’s quite easy to think about an healthcheck API (one per each microservice) which basically trigger a CI job that “open the circuit” but not from a function standpoint, but using API Gateway instead to avoid to trigger functions pointlessly. It means no costs for temporary unavailable service, and even faster response since functions shouldn’t have to be triggered to return it’s unavailable state.

We’d like to discuss about this kind of implementation, we think Serverless – thanks to many other technologies – will disrupt the way we are developing applications, just like Docker did but with a little bit more focuse on optimizing costs.

Please share your thoughts and get in touch at