Microservices Design Patterns Part 3 : Patterns Continued(Chained, Message/Event based)

In previous article we learned about proxy and aggregator composition pattern for microservices. In this article let us have a look on other composition patterns

Chained pattern

In this pattern the request is received by the one service (Service A) which may decide to communicate with second service (Service B), which in turn could call the third service (Service C). The single consolidated response is produced by the first service (service A) which received the request initially.

Example

Think about the hypothetical scenario of money withdrawal at ATM’s. You use your card at ATM (service A) which interacts with the Bank’s Server (Service B) which may call other service like balance check, transaction validation and so on (service N) and based on all these steps and based on the response ATM either allows the transaction or declines it.

Message or Event based pattern

This pattern is one of the complex but widely used (probably abused as well) pattern in enterprise implementations of microservices.

Most of the microservices implementation choose REST as preferred way of communication with and between microservices. Some of the reasons for using REST are

• Its well understood by most
• With frameworks like Spring Boot, Drowizard, Restlet, RestEasy. It becomes very easy to use and implement.
• Data transfer with lightweight JSON format.

But the limitation with REST is that, its synchronous and blocking in nature. Though we can use non-blocking frameworks but still the issue of being synchronous will be there.

One of the solutions to this is using message queues instead of REST request/response. Where one service publishes a message to queue and the other service, on receiving the message acts accordingly. This message is in the format which is understood by all the participating services.

This pattern is implementation of publish-subscribe pattern in microservices world and all the principles of the pub-sub are applicable. There is no limitation of the format of message, the only requirement is participating services should be able to understand the message. The message is serialized at the publisher end and de-serialized at subscriber end.

It is very rare to see a microservice implementation based alone on this pattern, usually a combination of REST and pub/sub is used in microservice implementations.

Example

Assume a scenario of status update notifications in any e-commerce application. There will be multiple services like emailing, SMS, invoicing, tracking etc. Each service performs its job and sends a message to queue, which may be same or different and then the next service does its job.

In next article we shall be covering implementation patterns. Please share your views, comments or questions, i would be more than happy to explore and answer them.