With the advent of the microservices revolution, the Enterprise Service Bus has also seen a change, where it has now been replaced by some similar solutions, but with the advantages of far better scalability and the removal of single point of failure.

The ESB in application integration used to play the role of a central bus, which acted as an intermediary between the applications that wanted to communicate with each other. The ESB facilitated this communication by introducing common data formats and providing adapters through which the applications could talk to the ESB.

But the ESB still suffered two major drawbacks:

• Scalability: The ESB was a heavy piece of middleware that required a specialization to work with. The scalability of the ESB was hard due to the sheer amount of resources required to scale the bus, and this was even harder when the bus had to be scaled to support applications located in different geographies.
• Single point of failure: The ESB proved to be a single point of failure. Since all of the applications used to communicate through the use of a single central bus, if the bus fails, all of the applications will come to a halt. One question that may come here is, why can't we have more than one instances of the ESB deployed to provide high availability? The answer to this is that although we can have a highly available setup of an ESB available, it might be too costly in terms of the resource utilization and maintenance.

These two issues are really major concerns in the microservices architecture, where the services are distributed in nature and need to talk to each other to provide meaningful business outcomes. The ESB needs a transformation here.

To deal with asynchronous communication, the microservices architecture introduced the use of stateless message brokers. These message brokers were very lightweight in nature and overcame the challenges that were present in the ESB, while supporting most of the essential features from the ESB.

The use of these message brokers provided the following set of functionalities:

• Asynchronous communication through messages: These message brokers provide the facility for implementing asynchronous communication between the different microservices through the use of messages and asynchronous message communication protocols such as Asynchronous Message Queuing Protocol (AMQP).
• Support for common data formats: The message brokers support the use of common data formats in which the messages can be transformed.
• Easy scalability: These message brokers are very easy to scale by simply launching more instances of the broker and support replication across the multiple geographies.
• Removal of central point of failure: With the use of these stateless brokers, there is no single point of failure. If one of the message brokers goes down, the services can start routing the messages to the other brokers inside the infrastructure. Also, the messages that have been previously sent are not lost due to the presence of the replication functionality. This replication happens through the use of a message queue replication mechanism when we run the message broker in a master-replica configuration, where there is a master node and one or more replication nodes. When a message arrives, it is first written to the message queue on the master node, and then it is replicated across the mirror nodes. In case the master node fails, these connections are routed to one of the mirror nodes, which can then take on the responsibility of the master node.

This makes a very strong point in the use of message brokers for the integration of microservices-based application, and providing asynchronous communication between them.