Design Patterns for Microservices (Aggregator, Circuit and Proxy)

Welcome back to another article. As I promised in my last article, this article is about design patterns for microservices. Before I begin if you are new to microservices you can refer my previous articles regarding microservices. I have published two articles which are introduction to microservices and best practices for microservices. If you are in this software engineering stream at least couple of years you already heard about design patterns. In this article I will be explaining about design patterns for microservices. As you know this article will cover mainly three design patterns and those are,

1. Aggregator design pattern
2. Circuit braker pattern
3. Proxy pattern

So let’s move one by one.

1. Aggregator Design Pattern

Aggregator design pattern can be implement in three different ways. Those are,

1. Parallel /Scatter gather
2. Chain
3. Branch

let’s get an example to explain those three types. let’s say we have to design a microservice system for a school.

service 1- To get students personal information

service 2- To get students absence information

service 3- To get student marks for subjects

service 4- To get extra curricular activities information that student involves

Then we have two consumers those are attendance management system and student colors management system.(school colors are giving to the students who are exceptionally perform on certain stream it can be a sport or any other extra curricular activities )

So in microservices as you know we are implementing one service per each which is independent from each other. But in here attendance management system needs to consume student personal information and student absence information. student colors management system needs student personal information and extra curricular activities information. So now how do we solve this?

What we can do is we can create one service to consume those two microservices which we need and give response back to the consumer.

Parallel/Scatter gather

In parallel aggregation what happen is we can send a parallel call to the personal and absence services and get those responses and aggregate those as a single response and sent back to the consumer.

Chain

Let’s say the absence information system has a dependency with personal information system. Therefore we can’t use parallel pattern. So what we can do is we can invoke personal information service and get the student code with other required information and we can pass this code to absence information system and get the student absence information and you can set the aggregator response back to the consumer.

Chain aggregator pattern takes some time more than parallel one. Because chain pattern will call one service then call another service like wise go on(It’s like a chain)

Branch

Branch pattern is all about based on some factors you decide to go this path or that path. It’s like the if condition in the programming based on some factors decide to do this or that. As a example, let’s say in banking application in the user interface you have to select deposit or withdraw. So if the user select withdraw it will connect with the withdrawal service else if the user select deposit it will connect with the deposit service and do the rest of the tasks.

Advantages of aggregator design pattern

1. Adding aggregation service are easier.
2. Easy to implement

2. Circuit Breaker Pattern

If your house is powered by electricity, then there must be circuit breaker. Circuit breakers are automatically operated electrical switches that protect electrical circuits from overloading or short circuiting. The behavior of the circuit breaker pattern is almost similar to circuit breaker design pattern.

In a distributed system we have no idea how other services will break. So as a developer you are responsible to keep service alive. Now let’s say we have five micro services and also we have a web server to call them. Now you get a request that means server allocate one thread to call that back end. Now the service is late so this thread is waiting until timeout. If this service is high demanding also if this get more and more request all these one by one thread in a thread pool get wait. Then the remaining request come to your service will be blocked or queued. However the web server will not recover because when it’s process the queue more and more requests will come. Some times there are scenarios where cascade failures may happen. cascade failures mean if one service is taking long time to response it’s affect to next service and then it affect to another service like wise go on.

We all know each and every services will fail or falter at some point in time. That’s the nature. Circuit breakers allow your system to gracefully handle these failures. What happen in the circuit breaker pattern is we can define timeout threshold . Let’s say as a example service A should response within 200 milliseconds. If number of requests is reaching the upper limit of the threshold(150 to 200 ms) then we can say service is failing slowly. If number of occurrences it’s not response within 200 ms(Maximum threshold time out)proxy will understand it’s not response. Then if any other request will come to access the service , those will not wait until the timeout. Those request go back to the consumer with the error message saying service is not available.

The circuit breaker has 3 states. those are,

1. Closed — When everything is normal, the circuit breaker remains in the closed state and all calls pass through to the services.
2. Open — The circuit breaker returns an error for calls without executing the function.
3. Half-Open — After a timeout period, the circuit switches to a half-open state to test if the underlying problem still exists. If a single call fails in this half-open state, the breaker is once again tripped. If it succeeds, the circuit breaker resets back to the normal closed state.

The consumer frequently sends a ping request to the service in the background time to time. If it is back, it will be connected to the service again.

3. Proxy Pattern

Sometimes client requirements may change time to time. Also services get update time to time. That’s why we must follow a proper versioning as I mentioned in my previous article which is best practices for microservices. It’s good to follow the semantic versioning where you have major, minor and patches.

When we updating our services time to time this is where proxy pattern comes in to the picture. Proxy pattern can be used to manage a few different versions of a particular service until all the consumers upgrade to the new version. So take a look at the below example.

In the above scenario in version 1.0 employee details are getting through the database using employee code(empcode). But in the version 2.0 employee details are getting through the database using employee id(empid). So in here what proxy does is if the consumers are sending the empcode which is in version 1.0 it will direct to the schema 1. When users are sending the empid which is version 2.0 it will direct it to schema 2. So now we can have both version of the services are available. When all the consumers updated to the version 2.0 we can decouple the version 1.0.

That’s it guys. You have reached to the end of this article and I hope you learn about those three design patterns which are aggregator ,circuit and proxy. So let’s meet from another article. Stay in touch.

References

Circuit Breakers and Microservices Architecture | Constant Contact Tech Blog