Circuit Breaker Part 2 -- Calculating Rates With Fixed Size Windows

This is a continuation of Part 1. In this article I will be going over the Fixed Size Window approach, which allows the circuit breaker to observe the results of the requests, and calculate a rolling failure rate. Fixed Size Window This implementation uses a circlar buffer of fixed size N. The buffer is used to store the result from the previous N results. You could decide on what sort of metrics or dimensions you need to record, for instance saving the outcome of each request. Additionally, we need to keep track of the overall aggregates somewhere. This aggregate can later be used to compute the ratio of the requests that fail to the total requests executed (aka failure rate).

Circuit Breaker Pattern Part 1: A Brief Overview

I recently read Microservices Pattern by Chris Richardson. The book highlights the different aspects of designing a microservice architecture. Some of the topics discussed include service decomposition, service communication, handling transactions, and CQRS ( Command Query Responsibility Segregation). The Circuit Breaker Pattern is one of those patterns presented to help improve the resiliency of your service communication. I thought it would be an interesting pattern to develop and talk about. I wrote a golang implementation of it, and in this blog, I will be describing an overview. The Use Case Suppose that you have two services: the Order and Payment services.

Microservice Pattern Chapter 1: Escaping the Monolithic hell

Introduction These are my notes from Chapter 1 on Microservice Patterns by Chris Richardson Chapter Summary Monolithic architecture pattern results in code that is deployed as single unit. Where as, the Microservice architecture pattern decomposes an application into a set of services, each with its own storage and deployment. Monolithic architecture is simple and quick to iterate on at the beginning, making it a good choice for simple application. Microservice architecture helps accelerates the velocity of software development by enabling teams to work autonomously on different services. In exchange for being able to better scale features and teams, microservices come with a drawback of the complexity.