Home » Software Development » Design Patterns for Microservices

About Yatin

Avatar photo
An experience full-stack engineer well versed with Core Java, Spring/Springboot, MVC, Security, AOP, Frontend (Angular & React), and cloud technologies (such as AWS, GCP, Jenkins, Docker, K8).

Design Patterns for Microservices

Welcome readers, in this tutorial, we will learn the basics of different design patterns under the Microservices architecture.

You can also check a tutorial in the following video:

Java Design Patterns Tutorial – video

1. Introduction

Before going any further in this tutorial I hope you understand what Microservices are and the principles behind them (such as Independent and Autonomous Services, Scalability, Decentralization, Availability, Isolation from Failures, Real-time Load Balancing, etc.). This will be an interesting long read. Have fun while reading!

1.1 Aggregator Design Pattern

Let us take a look at this design pattern.

  • This design pattern works on the mechanism where it aggregates the data from the different microservices and displays the result to the users
  • Based on the DRY principle. The Dry principle refers to the aggregation of business logic into composite microservices and aggregates that particular business logic into one service
  • Beneficial when we need an output by combining the data from the multiple microservices
Fig. 1: Aggregator design pattern

1.2 API Gateway Design Pattern

Let us take a look at this design pattern.

  • It is a design pattern that acts as a single point of contact for incoming requests, decides which microservice to send the request to get the data, and also helps in aggregation of data from different microservices
  • Support authentication responsibility for microservices
  • Can covert the protocol request from one type to other
Fig. 2: API Gateway design pattern/figcaption>

1.3 Chain of Responsibility Design Pattern

Let us take a look at this design pattern.

  • It is a design pattern where the output of 1 microservice acts as an input for other microservice
  • Uses synchronous HTTP request or response for messaging
  • The disadvantage of this pattern is that the response time for a single output can be much longer and the recommendation is not to make any longer chains
Fig. 3: Chain of Responsibility design pattern

1.4 Asynchronous Messaging Design Pattern

Let us take a look at this design pattern.

  • Interaction between the different microservices is not dependent on one and another and they do not have to communicate with each other sequentially
Fig. 4: Asynchronous Messaging design pattern

1.5 Database or Shared Database Design Pattern

Let us take a look at this design pattern.

  • This design pattern talks about that either a microservice will have its separate database or two or more microservices can share a common database
  • Solve problems like:
    • Like data duplication and inconsistency
    • Different services having different storage needs
    • Data denormalization through shared databases per services
Fig. 5: Database or Shared Database design pattern

1.6 Event Sourcing Design Pattern

Let us take a look at this design pattern.

  • This design pattern talks about generating an event for every event that has occurred in the database or changes in the application state
  • Offers to support auditing of who did what and when and helps in restoring the application state in case of a failure
microservices design patterns - Event Sourcing
Fig. 6: Event Sourcing design pattern

1.7 Branch Pattern Design Pattern

Let us take a look at this design pattern.

  • This design pattern talks about simultaneously processing the requests and responses from two or more independent microservices
  • Requests are not passed in a sequence
  • Extends the Aggregator design pattern and provides flexibility to produce responses from a single chain or multiple chains

1.8 Command Query Responsibility Segregator (CQRS)

Let us take a look at this design pattern.

  • Used when we want to query for a specific data
  • The application is divided into 2 parts: Command and Query
  • Command part handles all the requests related to CREATE, UPDATE, and DELETE
  • Query part handles the materialized views which are updated through a sequence of events

1.9 Circuit Breaker Design Pattern

Let us take a look at this design pattern.

  • This design pattern is used to stop the process of request and response if the service is not working
  • In this design pattern, when the number of failures crosses a threshold limit, the circuit breaker trips for a particular period, and all the attempts to invoke that service will fall in that particular period. Once that period is done, the circuit breaker will allow a limited number of requests to pass through & if success resume back to normal operation else it will show failure again and the time will begin
  • Offers no exhaustion of network resources and user experience is kept on a good note
microservices design patterns -  Circuit breaker
Fig. 7: Circuit breaker design pattern

2. Decomposition Design Pattern

Let us take a look at this design pattern:

  • It talks about breaking an application into small autonomous units and is done logically
  • The application is broken down based on three thing’s i.e. Sub-domains of application, Business capability, and Strangler or Vine pattern

2.1 Strangler Design Pattern

Let us take a look at this design pattern.

  • It is a design pattern that offers a way to break the monolithic application into smaller autonomous units
  • It is a pattern to incrementally transform the monolithic application into microservices by replacing a particular functionality with a new service. Once the new functionality is ready, the old component is strangled, and the new service is put into the use and old component is decommissioned altogether
  • This pattern helps to achieve the highest code quality, follow TDD for business logic, and SonarQube integration with the deployment
  • This pattern follows 3 steps i.e. Transform (i.e. Develop new component independently), Co-exist (i.e. Let both new and old component exists), and Eliminate (i.e. Delete old component from Monolithic architecture)

2.1.1 How to select which component(s) to Strangler/Refractor first?

  • Select a simple component if you’re a newbie to this design pattern. This ensures practical knowledge, best practices, etc.
  • If a component has good test coverage and less technical debt linked to it
  • If component which is better suited to the cloud and having scalability requirements
  • If a component has frequence business requirements and requires frequent deployment

That is all for this tutorial and I hope the article served you whatever you were looking for. Happy Learning and do not forget to share!

3. Summary

In this section, we learned different design patterns that are taken into consideration while designing a microservice architecture.

You can download the high-resolution images from the Downloads section.

You can read more about Microservices here

4. Download the High-Resolution Images

Download
You can download the high-resolution images of this tutorial here: Design Patterns for Microservices

Last updated on Oct. 8th, 2021

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions

 

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments