Messaging Patterns in Microservices — Part I
In my previous article, I mentioned that transport independence is the basis of microservices and is necessary to develop sustainable microservice architectures. You can reach my previous article with this link. There are two different aspect of a message interaction in microservices:
- Synchronous/Asynchronous (solid / dashed line) : The message expected/ does not expect a response.
- Observer/Consume(empty/full arrowhead): The message is either observed (others can see it too) or consumed (others can’t see it).
Everything can be turned into a mathematical formula.
A simple mathematical formula can be used to categorize all existing messaging patterns based on the above principle. we assume to have only one message model and two microservices. We assume also that our entire communication model is built on this structure. In this case, we can use the formula m/n where m is the number of message patterns and n is the number of microservices. So, we can use the 1/2 function to categorize a messaging pattern where we have only one message model and two microservices.
1/2 or one message/two services pattern
In this pattern, You enumerate the four permutations of the sync/async and observe/consume axes.In general, enumerating the permutations of message interactions, especially with higher numbers of microservices, is a great way to discover possibilities for microservice interaction patterns.
request/ response
It is a pattern based on the transporting of HTTP messages, which is known and widely used by almost everyone. In this pattern, messaging is synchronous. The microservice that initiates the communication is definitely waiting for a response from the other microservice. Only the target microservice recognizes and knows the message. No one knows about this message between them. In fact, this messaging model includes traditional REST-style APIs. Also, the first generation microservice architectures also preferred this messaging model.
Of course, there are many tools to highly robust the interaction and communication model here.
So, if the cardinality of the target microservices is greater than a single instance, can we talk about continuing to use the same messaging pattern?
No. Unfortunately, we cannot use the same messaging model. These types of messaging patterns are called actor-style patterns. Each microservice in the listener role processes messages in turn. It then transmits the required response regarding the messages processed to the source.
sidewinder
You can use this pattern if you are not interested in the details of network traffic, and you need a very basic asynchronous messaging model. This pattern communicates intent and the message is observable. your main intention cannot be to get a reply directly from the target, and it is not a priority for you which services consume to this message. This is also a good example of the way a model generates new ways of looking at systems by enumerating the combinations of elements the model provides.
winner-take-all
This pattern is one of the most common patterns used in distributed system architectures. Messages are asynchronous, so no response is needed. one or more consumer messages listen to the message sent from the source. At least one consumer receives and processes the message sent by the source. The consumer, — which is described as a winner, is responsible for the execution of process. In this pattern, Only intention is shared like sidewinder. Message queues are used in many approaches of this pattern. There is another approach that is used a lot more instead of this approach. You can use a sharding approach and ignoring messages that don’t belong to your shard
fire-and-forget
This pattern is another one of the most common patterns used in distributed system architectures. In fact, this is the most ideal and pure method used for microservice communication in distributed systems. In this pattern the message is sent to the outside world and it doesn’t matter who is processing it. Any service that cares about the message can receive and process it. The most important point to remember is that all microservices that care about this message have to listen to the message. In this pattern, services can receive and process the same message multiple times. In general, this method is preferred to provide a delivery guarantee at the service layer. But it is imperative that the processing and capture tasks are idempotent. Otherwise, data stability, integrity, and precision will be corrupted.
In this article, I tried to explain only one messaging pattern and its forms. I will talk about the following topics in the second part of this article.
- 2/2 or two messages / two services pattern : request/react, batch progress
- 1/N or one message/ n services pattern: orchestra, scatter/gather
- M/N or m messages / n services pattern: chain, tree
