The main concept of asynchronous communication is basically messages flowing from one peer to another. These messages can be some command or some events, driven information. Asynchronous communication is typically of two types:

• Message based
• Event based

Both types work in the same manner. A message is triggered from the called service after finishing its work which lets the other services do their own work. There is no well-defined difference between these communication patterns, but message-based communication works on peer-to-peer communication, and event-based communication works based on publisher/subscriber. In message-driven communication, cohesion is obtained with a predefined queue name or channel. In the case of event-driven or command-based communication, the predefined format has to be shared. As shown in the following diagram, Service A is pushing the message to a predefined queue, which means logically, Service A knows of the existence of Service B as it knows that Service B will listen to the message and take further action on it:

On the other hand, in event-based communication, Service A will raise an event and then forget about it. Maybe, Service B uses it or it may be Service D or any other new service which is added very recently. There could be a case when no service is reading it at all. So, there is a slight change in mindset. As shown in the following diagram, Service A finishes its work and publishes it without knowing whether it is useful for anyone or not. However, in the prior method, Service A knows Service B will listen to it. There could be data in the message sent by Service A, in a format which only Service B can read or which is useful only to Service B. In event-based communication, there is a general format and data of finished work, as it can be read by any old or new service. So, the format of the message or event should be standard across the microservice. The following diagram describe the scenario for event driven communication:

As both share common properties, from now onwards, to explain the characteristics of these two types of communication combined, we will refer to them as message-driven communication. The following are the points that describe the pros of message-driven communication:

• As services are decoupled in asynchronous communication, easy scaling is the first benefit one can get from this style. Newly developed services can be added silently to receive messages/events and act on it. The sender doesn't need to know about the new receiver.
• In message-driven communication, back pressure can be handled in a better way than with synchronous communication . If the producer is creating the message more quickly than the consumer is consuming it, then there will be lots of messages in the queue to process. This situation is called back pressure. In this particular situation, the consumer can do two things. First, they can raise an event to tell the producer to slow down. Second, they can add more workers silently. This kind of problem mostly comes in event processing.

Here are the disadvantages of asynchronous communication:

• Operation complexity will increase, because message broker has to be installed, configured, and maintained with high availability, which is an overhead.
• It's hard to see what is happening in a system. There are messages flowing and action is being taken by different services, but due to the autonomous nature, it is hard to get a clear view of what's happening in the system. Due to this, extra effort is required at the time of debugging any issue.
• Sometimes, it is hard to convert any request/response structure to message-based communication. Consider a train booking system. Without checking the availability at run time, booking a ticket is not possible. In these kind of scenarios, synchronous communication makes sense.