Design Patterns for Microservices

🎇Aggregator Design Pattern

  • Services: Service to get personal information, Service to get leave information, Service to get appraisal information and service to get project allocation information.
  • Consumers: Attendance Management System, Project Management System.

✨Parallel or Scatter gather pattern

  • Now the Attendance Management System need to get the personal details and leave information which are working independently.
  • In order to get those information, what we can do is invoke the information from both independently working services in to new service aggregate them and send back to the consumer.

✨ Chain design pattern

  • Let’s say our consumer Attendance Management System sends request to invoke the leave information from a particular employee along with the EmpId which is not consumed by leave information service. Instead of that leave information service does consume EmpCode. But it does have a dependency with the personal information service which has a field of EmpId.
  • Now what we can do is invoke information from the first service in their you will have EmpCode. Then with these information, you will find the leave information as well.
  • Then you can aggregate them and send back to the consumer.

✨ Service branch pattern

  • Let’s say Project Management System requires personal details of employee along with his branch (which he is working at).
  • Then the service request first go with the personal information service and then go to the specific branch service to collect his branch details.
  • Likewise, by based on a decision, the service request can decide the path of branch.
  • In this pattern, we need to consider more about the response time. For an example, if every services has their own validation mechanism to validate the response/request it will take time. But, if you have proper ID management system would be fine for your authentication and authorization mechanism.

🎇Circuit Breaker Pattern

🎇Proxy Design Pattern

  • When the request sends EmpCode, the proxy service will direct it to the Schema1 while the request with EmpId will send to the Schema 2.
  • In this case you can have both version of services. That means you can independently deploy your services without interfering your consumers. When you realize, the Schema 1 does not get any request from your users anymore, then you can decommission it. In order to do that semantic versioning is very useful.
  • In order to discover the all existing services and its versions for the customers, we can use Service Discovery Tool as a third party. When you have this, the service proxy will ask from it where the requested service is relying on.
  • When you implement the proxy pattern make sure you will consider about the number of thread pools and efficient thread handover mechanism.

Stay Safe !!!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store