Microservices Design Patterns

A sneak peek at microservice design patterns.

To begin with, what are Microservices?

An architectural style where our application is composed of modules that can be independently developed, deployed, and maintained.

Pros?

• reduce complexity
• reduce risk
• easier to develop in parallel
• scale
• cost-effectiveness(services that have less CPU utilization can be run with fewer resources)
• flexibility(each module can be built which technology that fits the job)

Cons?

• Requires extra time to set up and managing independent parts for deployment processes
• Too many repos to handle(many overheads)
• Switching between projects for development is cognitive overload

So what are the ways to build a good solution to compose microservices together?

• Asynchronous Messaging Microservice Pattern
• Shared Data Microservice Pattern
• Aggregator Microservice Pattern
• Proxy Pattern
• Chained Microservice Pattern
• Branch Microservice Pattern

Let's detail them a little bit.

Being synced may cause being blocked

Asynchronous Messaging Microservice Pattern

In service architecture, being synced may cause being blocked. If this case is what you need because of a monetary transaction, that is cool. However, there are other cases we would like a service like sending info mail to customers or a logging service to not block our main business logic. For this purpose, using message queues like RabbitMQ or Kafka is an option. Configuring microservices according to event-driven architecture(Kafka pub-sub) is an option. Using WebSockets is another option. Choose wisely.

Shared Data Microservice Pattern

The shared data pattern is liked by many as an anti-pattern, but seen by others as an old concept that should no longer be applied. However, there is considerable distance between the ideal world and the real world.

In the ideal world, all projects are greenfields and nobody needs to work on legacy code or change the architecture of a monolithic application. However, the reality is not that. Legacy projects are now serving users. These applications are online stores, financial applications, social networks, and a myriad of businesses that require upgrading to achieve automation, scalability, and resilience.

The shared data pattern search just speeds up the process of change for these legacy applications. It has the positive benefit of giving the development team time to segregate the information from the database and evaluate the consistency of the data.

Aggregator Microservice Pattern

In the previous section, we saw the operation and applicability of the shared data pattern design. We know that the pattern mentioned here is temporary; that is, it is a pattern for some transition scenarios from monolithic to microservices because of the risk over some components. In this chapter, we will move on from the shared data design pattern to apply a more consistent pattern with good development practices to microservices.

It will be presented and applied to the aggregator design pattern. Precisely, with the new pattern, we will apply Command Query Responsibility Segregation (CQRS) and event sourcing to our microservices. Another interesting point is that we will restructure our storage distribution. Each has the same technical structure, but is separated by having different domains. As the domain of each of these microservices is set, it can receive completely different technical developments.

Proxy Pattern a.k.a Circuit Breaker Pattern

The proxy design pattern is a variation of the aggregator design pattern and is used when we want to combine or encapsulate access to microservices, and when no value needs to be aggregated. Basically, it allows direct access to the business, but isolates the technical layer. Just like the aggregator design pattern, the proxy design pattern allows independent scalability, both on the x-axis and the z-axis.

The proxy design pattern can be seen as a more purist pattern because it allows a single point of access to microservices, but there is generally no need for communication between microservices. Another strong feature relative to the proxy design pattern is the flexibility to apply other patterns while the proxy is applied.

Chained Microservice Pattern

The chained microservice pattern is like it is said, chained microservices. What we mean here, there will not be using anything in between the client and service layer. Instead, we will allow the client to communicate directly with the services and all the services will be chained up in such a manner that the output of one service will be the input of the next service. The following image shows a typical chained pattern microservice.

Branch Microservice Pattern

Branch microservice is the extended version of aggregator pattern and chain pattern. The client can directly communicate with the service. Also, one service can communicate with more than one service at a time. This pattern can also be used to call different chains, or a single chain, based upon the business needs.

Hope you like it.

Happy coding,

S.