We know the simplicity and practicality of REST (Representational State Transfer), mainly because this knowledge is already very well-established in the market. The number of tools and frameworks for the REST layer also help with its popularity.

REST calls have a synchronous character, and synchronous calls are blocked due to the request/response model of the technology. This type of call is often necessary for the business of the application, although it is not the most indicated. This shows us there is some level of coupling between the microservices of the application.

A purist microservice must be fully capable of performing the task for which it has been assigned without the need for communication with another microservice. Another feature of a puristic microservice is that it performs a task without the need to return a response by simply receiving the request and doing what needs to be done. In this sense, the asynchronous messaging design pattern is a model that naturally works with purist microservices. Due to the characteristics of the pattern, messages are sent and there is no response or propagation of information to the other microservices. So, we're saying that the request generator does not need to be told what's going on to continue working; it just sends a message and knows that somewhere, some microservice will get a message and execute what is determined.

This pattern is undoubtedly the most scalable of all; due to the asynchronous character of microservices, there is an opportunity to complete the tasks without causing any inconvenience to the final consumer of the application.

The asynchronous messaging design pattern can be used with any other pattern. Also, when it comes to the communication model between microservices, this is the pattern most indicated to be used.

Looking at the following diagram, we can understand the flow of the asynchronous messaging design pattern a bit better. In this diagram, we have Service A that establishes synchronous communication with Service B, Service C, and Service D. In turn, Service B, Service C, and Service D identify that there is a task to be performed, but this task is not necessary for the continuity of the workflow of these microservices, so then they send a message to a queue. On the other side are Service E and Service F, listening to the queue to perform a task using the message that was sent. This communication model, where a message is sent and no type of response is expected, is called an asynchronous model. It is exactly this type of work that the asynchronous messaging design pattern is used for:

Now that we have seen the behavior and how the asynchronous messaging design pattern works, let's apply this pattern to our application.

To use the asynchronous messaging design pattern in our news portal, we will create a new microservice responsible for storing recommendations for users of the application. This microservice will be the RecommendationService microservice and will work in two ways—listening to messages sent to a queue, and with an HTTP API connected directly to the application proxy. In this way, we will store the information about the news preferences of a given user and we will be able to consult the preferences recorded directly by an application API.

In addition to the asynchronous message that the RecommendationService microservice will use to create the recommendation, it will also use a synchronous call to complete the recommendation information with the UsersService microservice's data.

The following diagram summarizes how the distribution of our microservices will be at the end of this chapter. As you can see here, it is similar to the preceding diagram that we used to understand the operation of the asynchronous messaging design pattern: