Communication Patterns

When communicating between services, we can identify two patterns: synchronous vs asynchronous. When we say sync/async here, we are not talking about using async/await in our code, but rather about whether the communication pattern involves waiting for a response (synchronous) or knowing another part of our code will handle the response, whenever/if it may arrive (asynchronous).

Synchronous Communication

An HTTP Call is a synchronous communication. We perform a request and stay waiting for a response; we fail if no response is given or if it times out. Even if we are using async/await or promises, futures, etc this is a sync communication.

Asynchronous Communication

Instead of waiting for a response or timing out, when using an async communication pattern it is expected that the operation being performed is or may be long lived, due to the nature of distributed systems.

Event-based communication is used to communicate between services, it is mostly useful for performing writes. We may still use sync communication for performing reads, since that is usually what we want when reading data, we wanna wait until we get the data to show it.

We will quickly realize that our services will use both kinds of communication, and that is fine: the right tool for the job.

The Event Broker

When communicating asynchronously, we will be sending messages from one service to another. In order to guarantee its delivery, we will relay the message to an Event Broker, which will be in charge of making sure the message reaches its destination.

The Event Broker is a service that receives messages, possibly stores them on disk, and sends them to the correct parties, depending on configuration.

A Message is just a serialized piece of data, think a DTO. Messages are sent by Producers and received by Consumers

For the Suite 3.0, we are using RabbitMQ. Read more at implementation details

Events vs Commands

Messages may have different intents. We can define two kinds of messages:

A Command is a Message that is instructing a specific Consumer to perform an action. The Consumer, after processing the message, will usually want to reply, we call those replies **Response**s.

An Event is a Message equivalent to a notification. When something happens in the ecosystem, events are published to let the rest of the ecosystem know of what just happened.

Commands are Sent, Events are Published.

When naming messages, commands should be a verb + a noun, like CreateUser, since they are commanding an action. Events on the other hand, represent an action that has already happened, hence they are usually a noun + verb in past tense, for example UserCreated.