Applying the message broker and queues

Unlike the patterns we have worked on so far, there is effectively no model of data orchestration or response consolidation when we use the asynchronous messaging design pattern. Due to the pattern's asynchronous communication model, there is no type of response, so there is no data orchestration.

In fact, a gauge of whether the microservices work is receiving messages from a queue or receiving messages and properly performing the tasks upon receipt.

In this sense, it is important to keep in mind which type of tool to use for sending messages. If the messages have a high level of criticality, it is interesting to use some tool that is transactional for the processing of messages. ActiveMQ, RabbitMQ, and Kafka in their most current versions are really great asynchronous communication platforms.

In our application, we are already using RabbitMQ, and we will continue with it. However, we should make some changes to the NewsOrchestrator code. The changes are made so that upon receiving a request to display a news article, the user ID and the news data that the user has requested are sent to the RecommendationService microservice. For this, we will use a pub/sub model.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.143.4.181