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
.