Skip to main content

MicroServices Design Patterns

Aggregator​

This pattern we can call it as website or program that collects related items of data and display them.

In regards to microservices world, This pattern proves to be beneficial when you need an output by combining data from multiple services.

Example

If you have two services each having their own database then an aggregator having unique transaction ID, would collect data from each individual micro service and apply the business logic and finally publish it as REST endpoint.

API Gateway​

Micro services are built in such a way that each service has its own functionality. But, when an application is broken down into small autonomous services, then there could be few problems developer might face.

  1. How can I request information from multiple sources?
  2. How to handle multiple protocol requests? etc...,

The solution for this kind of problems could be the API Gateway design pattern. API gateway can convery the protocol request fron one type to other.

Chain of responsibilities​

Chain of responsibility produces single output which is a combination of multiple chained outputs.

Example:

If you have 3 services lined up in a chain. First the request is received by Service-A and process it and communicate with Service-B. Finally Service-B communicates with Service-C to generate the consolidated output.

tip

All these services use synchronous HTTP request or response for messaging. Also, until request passes through all services and the respective response will be generated until client will not receive any output.

So it is also recommended to not to make a long chain, as the client will wait until the chain is completed.

Async messaging​

In this design pattern all services can communicate with each other but they do not have to communicate with each other sequentially.

note

chain of responsibility is synchronous and client gets blocked, so Aync messaging solve this problem because it is asynchronous messaging.

All services communicate asynchronously and whichever is completed then it will wait in queue until required services to finish. once all done then send response back to client.

Event Sourcing​

The event sourcing design pattern creates events regarding the changes in the application state. These events are stored as a sequence of events to help developers track which change made and when. You can always adjust the application state to cope up with the past changes.

Circuit Breaker​

Circuit breaker is used to stop the process of request and response if a service is not working.

Example:

let’s say a client is sending a request to retrieve data from multiple services. But, due to some issues, one of the services is down. Now, there are mainly two problems you will face: first, since the client will not have any knowledge about a particular service being down, the request will be continuously sent to that service. The second problem is that the network resources will be exhausted with low performance and bad user experience.

So, to avoid such problems, you can use the Circuit Breaker Design Pattern.

With the help of this pattern, the client will invoke a remote service via a proxy. This proxy will basically behave as a circuit barrier. So, when the number of failures crosses the threshold number, the circuit breaker trips for a particular time period.

Then, all the attempts to invoke the remote service will fail in this timeout period. Once that time period is finished, the circuit breaker will allow a limited number of tests to pass through and if those requests succeed, the circuit breaker resumes back to the normal operation. Else, if there is a failure, then the time out period begins again.

Decomposition​

Microservices are developed with an idea on developers mind to create small services, with each having their own functionality. But, breaking an application into small autonomous units has to be done logically. So, to decompose a small or big application into small services, you can use the Decomposition patterns.

With the help of this pattern, either you can decompose an application based on business capability or on based on the sub-domains. For example, if you consider an e-commerce application, then you can have separate services for orders, payment, customers, products if you decompose by business capability.