Messaging in Microservices Architecture

It is very important to carefully consider the choice of messaging mechanism when dealing with microservice architecture. In a monolithic architecture, it is not a concern, as the business functionality of the components gets invoked through function calls.

There are no set rules for making a choice between the various frameworks or protocols for microservice architecture. However, there are a few points worth considering here. First, it should be simple enough to implement, without adding any complexity to your system. Second, it should be very lightweight, keeping in mind the fact that the microservice architecture could heavily rely on interservice messaging.

With microservices, messaging can be done in two ways.

Synchronous messaging

Synchronous messaging is when a timely response is expected from service by a system, and the system waits until a response is received from the service.

Asynchronous messaging

Asynchronous messaging is when a system does not immediately expect a timely response from the service, and the system can continue processing without blocking that call.

To enable messaging, a REST API with a preferred message format(JSON/XML) can be used to communicate back and forth with the user interface.

In the preceding diagram, the user would get a response while the system is interacting with the Sales DB and/or Orders DB service(s) and fetch or push the data to their respective databases. The calls from the user (via the user interface) to respective services would not block new calls from the same or different users.

This lesson is part of the course Microservices with C#, .NET Core and Azure. Use navigation on the right.