What are the types of microservices communication?

Microservices architecture structures applications as a collection of independent and loosely coupled services; each service can perform a specific function, allowing flexibility and agility. These services can be developed, deployed, and scaled independently, providing better scalability, fault tolerance, and maintainability.

The communication between microservices can lead to significant challenges and disruptions. Microservices communication can be classified into various categories depending on the communication style, protocol, and methods used for communication.

Communication style

Regarding communication style, there are two primary types:

• Synchronous

• Asynchronous

Synchronous communication entails the client patiently awaiting a response from the service before proceeding. In contrast, asynchronous communication allows the client to continue its processing without waiting for an immediate response from the service. Whenever a response is available, the client is notified. The illustration below gives an idea of how the two communication style works. In asynchronous communication, the message, as well as request-response protocols, can be used.

Communication protocols

Regarding communication protocols, two prevalent options are HTTP and messaging. HTTP is a widely adopted protocol that facilitates request-response interactions and resource-based APIs. On the other hand, messaging protocols are designed to enable event-driven communication and the utilization of message queues, supporting asynchronous communication patterns. We also have a different set of communication protocols based on events.

Let's discuss the communication between services in the subsequent section.

HTTP communication

The hypertext transfer protocol (HTTP) is a widely used application protocol for communication over the Internet. HTTP operates on the principles of request and response, wherein one server sends a request to another server, and the server responds. Typically, the client formulates requests using HTTP commands, while the server furnishes data in the form of documents. It is crucial to grasp the significance of HTTP since it serves as a pivotal protocol driving APIs.

In the illustration above, service A requests service B and awaits the response. This makes the two services coupled and depend on each other for communication. The services can be decoupled by enabling asynchronous communication between them, as illustrated below.

In the illustration above, service A requests service B and doesn't wait for the response. Instead, service B responds with a status URL where service A can check the response later. This decouples the services and removes the dependency of waiting for a response but adds the complexity of checking a response.

Message communication

Another protocol that can be used in microservices is message-based communication. In contrast to HTTP communication, services do not directly communicate with each other. Instead, the services use a message broker to push the messages that other services subscribe to for communication. This model loosely couples all the services eliminating the complexity of HTTP communication.

In message-based communication, the message is pushed to the message broker, and there is no URL received because the service only knows the message has been sent without knowing if the intended service receives it. This is an added complexity that is solved by responding with a message ID to the requesting service, which then can use the message ID to query about the message from the intended service. Still, there is a coupling between the services to agree on message structure and query the statuses of each other.

Event-driven communication

Event-driven architecture (EDA) uses events to drive data and application behavior and empowers applications to take action or respond to these events. With an event-driven architecture, clients receive data automatically when an event occurs within the application; the primary objective is to establish loosely coupled services in contrast to other communication protocols.

Though the messaging queue is also still needed in EDA, the services are loosely coupled here as they only react to the occurred events leaving the complexity of checking message delivery or agreeing on specific structures.

Conclusion

It's worth noting that different communication patterns can be combined within a microservices architecture based on the requirements and the nature of the interactions between services. For example, Netflix and Uber use microservices to handle different functionalities and communicate using a combination of HTTP requests and event-driven messaging queues.