Transactional messaging provides the following benefits:

Two-Phase Commit isn't required because we are writing messages in the local database, rather than sending them directly to the Message Broker. We can use the same transaction as used by the service layer. If the service layer fails, the transaction is rolled back with the message as well. This approach removes the need to send a message to the message broker.

If the Message Broker fails for any reason, no messages are lost, because we are writing in the database on both the sending and receiving side. While the message broker is repaired, we can send messages from the message database.

The one drawback of transactional messaging is that it is quite complex to set up for a distributed application because it means there are extra jobs for writing messages in sending and receiving databases. Jobs should also be written to read unprocessed messages.

We have now seen both simple messaging and transactional messaging used in an asynchronous inter-service communication context. So, let's now look at two further properties of the asynchronous communication style; they are as follows:

One-to-one service communication

One-to-many service communication