When talking about messages and messaging systems, there are four fundamental elements to take into consideration:

• The direction of the communication, which can be one-way only or a request/reply exchange

• The purpose of the message, which also determines its content

• The timing of the message, which can be sent and received in-context (synchronously) or out-of-context (asynchronously)

• The delivery of the message, which can happen directly or via a broker

One-way vs. request/reply patterns

The most fundamental aspect of a messaging system is the direction of the communication, which often also determines its semantics.

The simplest communication pattern is when the message is pushed one way from a source to a destination; this is a trivial situation, and it doesn’t need much explanation:

A typical example of one-way communication is an email or a web server that sends a message to a connected browser using WebSockets, or a system that distributes tasks to a set of workers.

On the other side, we have the Request/Reply exchange pattern, where the message in one direction is always matched (excluding error conditions) by a message in the opposite direction. A typical example of this exchange pattern is the invocation of a web service or sending a query to a database. The following illustration shows this simple and well-known scenario:

The Request/Reply pattern might seem a trivial pattern to implement, however, as we’ll see later, it becomes more complicated when the communication channel is asynchronous or involves multiple nodes. Take a look at the example represented in the following illustration:

With the setup shown in the illustration above, we can appreciate the complexity of some Request/Reply patterns better. If we consider the direction of the communication between any two nodes, we can surely say that it’s one way. However, from a global point of view, the initiator sends a request and in turn receives an associated response, even if from a different node. In these situations, what really differentiates a Request/Reply pattern from a bare one-way loop is the relationship between the request and the reply, which is kept in the ...