Message brokers improve the reliability and evolvability of systems

Most web applications prefer to use REST and RPC services to power their communications. They are good choices for a system that relies on point-to-point data transfer, forwarding a message from one process (typically called the client) to another process (called the service or the server) with low latency.

The client could itself be a service, calling another service to accomplish a task. But there is a direct network connection established between the client and the service for data delivery.

In contrast, asynchronous message-passing systems use an intermediary called a message broker, sometimes referred to as a message- queue or message-oriented middleware, to deliver messages.

The message broker's core responsibility is to deliver messages.

When a message broker is involved, one process sends a message to a named topic or queue, and the broker ensures that the message is delivered to one or more consumers of or subscribers to the queue or topic.

There is no direct connection between the sender and the recipient. But the characteristics of this indirect message transfer lead to many advantages, making a message-oriented system a superior option compared to REST or RPC services.

Message brokers act as a buffer.

They store messages temporarily if the recipient is unavailable or overloaded. Since the message is asynchronous, no sender is waiting around for a response. By acting as temporary data holders, brokers can improve system reliability by smoothening the load curve on services over time.

If a process were to crash or become unavailable in the middle of handling a message, the broker could redeliver the messages, thus preventing messages from being lost.

Message brokers remove the need for service discovery.

Service discovery is a mechanism by which client processes can automatically detect and call specific services to fulfill a task. Because the message broker acts as an intermediary, and because consumer processes register themselves to the message broker to receive certain classes of data, the client (the sender of the message) is relieved of the burden of service discovery.

The service does not have to know the IP address and port number of the recipient service. This indirection layer is convenient in a cloud deployment where a cloud provider can often bring down virtual machines without notice.

Message brokers can deliver a single message to several recipients.

When a new service (component or method) is introduced in typical client-server applications, client systems change in tandem to invoke the new service. This dependency often leads to an explosion of connections between clients and services.

A broker reduces the complexity by acting as an intermediary. There are only two connections when a broker is involved: sender to broker and broker to the consumer. Sender and consumer never have to know about each other.

Message brokers increase system evolvability.

Because senders do not know about consumers, they are logically decoupled. Senders publish messages and do not care who consumes them.

This independence leads to cleaner boundaries between services, with clearly defined responsibilities. The architecture is also more sustainable because systems can introduce new consumers on the fly.

So the very nature of message-oriented architectures improves the reliability and the evolvability of systems.