Message Driven Architecture

Table of contents

Reading Time: 2 minutes

Here we will discuss the different types of messaging patterns used in Reactive Architecture.

Evolution of Communication

Since the real world is a perfect example of the natural distributed system, we can learn from it and apply its principles to build Reactive Systems. In the real world face to face conversation is synchronous communication. Over time letters have been introduced in the real world and that’s very much asynchronous communication. Over time we have introduced phone calls, video chats, etc as synchronous communication and similarly for asynchronous communications letters have been replaced by emails, text messaging has been introduced.

Now we have different options for both synchronous and asynchronous communication. But the key thing is that these communication channels should be used appropriately. For example, let’s say you have sent a text message to someone and then continue looking at your phone for the response whereas another person might not have read your text message due to various practical reasons. So expecting synchronous response via text messages is not appropriate.

Similarly in distributed software system appropriate synchronous or asynchronous messages should be used.

Message Driven Architecture

One of the key elements of Reactive Principles is that Reactive Systems should be using Message Driven Architecture.

Reactive System put an emphasis on Async, Non-Blocking messages.
Messages are sent without waiting for a response.
The sender may be interested in a response, but it comes asynchronously.

Advantages to Asynchronous and Non-Blocking

System resources can be released immediately without waiting for the response.
It reduces contention and potential for higher scalability.
Messages can be queued and delivered when the receiver is available.

Asynchronous messages are the backbone of Reactive Systems. Synchronous messages can also be used but that should be driven by domain requirements rather than technical convenience.

Messaging Patterns

Communication between Reactive Microservices can be

Each microservice can directly depend on other microservices, sending messages in a point-to-point fashion.
Each microservice can leverage a publish/subscribe message broker or bus to decouple it from another service.

Point to Point Pattern

Each service depends on other services directly.
Services are directly coupled to each other APIs.
Services know about and understand their dependencies.

Services publish messages to a common message bus.
Other services subscribe to the messages.
The publishing services and subscribers are completely decoupled with each other.
Publishers and Subscribers are coupled to only message format.

Both Point to Point and Pub/Sub can be done internally or they may leverage an external service. An external Message Bus, for example, Kafka, Rabbit MQ, Kinesis, etc can be used as transport for messages.