Communication between microservices

Microservices have revolutionised the way applications are developed and deployed by enabling the creation of systems and infrastructures from independent, self-contained components, offering flexibility, scalability and maintainability. One of the crucial aspects of this architecture that we are going to discuss here is the communication between the various microservices that make up an application. In this article, we will explore strategies and tools for effective communication between microservices.

Communication between microservices is a fundamental element in the architecture of this area, a software design trend that has revolutionised the way enterprise applications are developed and deployed. The ability of microservices to operate independently and collaborate with each other through well-defined interfaces has enabled organisations to build highly scalable and flexible systems. In this context, it is essential to understand the different types of communication that can be employed, as the choice of an appropriate approach can have a significant impact on the efficiency, reliability, and performance of the system. In this exploration, we will examine the various methods of communication between microservices, from HTTP calls to asynchronous messaging, providing a comprehensive overview of the options available and their advantages and disadvantages.

Complexity of communication between microservices: strategies and tools for an effective architecture

Communication between microservices, while essential for building highly scalable and flexible applications, can also be a considerable challenge given its complexity. Unlike monolithic applications, where each component interacts within the same context, microservices run independently and communicate across the network. This introduces an additional layer of complexity in terms of latency, reliability, and security. Selecting communication protocols, handling errors, synchronising data, and ensuring that services remain available can become intricate tasks that require careful planning and robust implementation.

In addition, the different technology used between microservices can add another layer of complexity. Each service could be developed in a different programming language, use different databases, or follow different design paradigms. Effective communication between these components may require the implementation of specific patterns and practices, such as message bus integration, API version management and comprehensive documentation.

Communication between microservices can be a challenge given their complexity

Due to the diverse nature of each project and its limitations in budget, development time and complexity, it should be noted that it is not recommended that all projects adopt a microservices-oriented approach. Despite the many advantages it can bring, this approach can have a substantial increase in both development and maintenance costs that not all projects can bear. Therefore, while microservices offer significant benefits in terms of agility and scalability, the complexity of their communication is a critical factor that needs to be carefully, strategically, and early addressed in the architecture of an application.

Microservices communication strategies

Communication between microservices is a fundamental part of ensuring the proper functioning of an application. To this end, this communication can take place both synchronously and asynchronously. On the one hand, synchronous communication implies that a microservice should expect an immediate response after sending a request to another microservice. This can lead to coupling between the two and latency problems if either experience delays but reduces complexity. On the other hand, asynchronous communication implies that microservices send and receive messages without actively waiting for a response, so that they can attend to other processes once they have sent such a message. This allows for greater flexibility and avoids latency problems but can complicate business logic and requires more management over potential failures.

Synchronous communication

One of the most common approaches, given the simplicity of its implementation, is synchronous communication between microservices, where one microservice makes a request to another and expects an immediate response. Different approaches are possible for this type of communication:

• HTTP/HTTPS: It is a communication protocol widely used in distributed environments. One microservice acts as a client and sends an HTTP request to another microservice acting as a server. This request may contain parameters and data necessary for the requested action. The receiving microservice processes the request and returns a response.
• REST (Representational State Transfer): REST is one of the most popular options for synchronous communication. It defines standards on how to design and structure web services. It uses the protocol mentioned in the previous point, HTTP, and, by means of its verbs such as GET, POST, PUT or DELETE, among others, it allows operations to be carried out on resources identified through URLs. Microservices expose RESTful endpoints that allow other microservices to perform specific operations.
• gRPC (Google Remote Procedure Call): gRPC is an open-source remote procedure call (RPC) system developed by Google. It allows microservices to communicate efficiently and securely using interfaces defined by IDL (Interface Definition Language). gRPC uses HTTP/2 for data transfer, which improves speed and efficiency.

In any of the above scenarios, communication between microservices is always sequential and a microservice requesting information from another microservice is always actively waiting for an immediate response, whether it is successful or not (Figure 1.).

Figure 1. Synchronous requests between microservices.

Asynchronous communication

Asynchronous communication between the different components is an essential strategy to achieve greater flexibility, scalability, and efficiency in the exchange of information. Unlike synchronous communication, where a microservice expects an immediate response, asynchronous communication allows microservices to send and receive information without relying on such a response, so they can more efficiently start new tasks. Some of the most used strategies for this type of communication are:

• Messaging Systems: Platforms such as Apache Kafka, RabbitMQ and AWS SQS provide messaging systems that allow microservices to send and receive messages. These systems provide queues and channels where messages are temporarily stored before being processed by the microservices for which the messages are intended.
• Publication and Subscription: In this strategy, sending microservices publish messages on specific channels, and receiving microservices subscribe to receive them. This allows multiple microservices to respond to the same event at the same time and different actions can be triggered in parallel.
• Event-Driven Architecture (EDA): Event-driven architecture implies that microservices generate events in response to changes or actions in the system. Others can be reactive to these events and act, accordingly, allowing for asynchronous communication.

This type of communication makes microservices more independent of each other (Figure 2.), resulting in low coupling and greater independence. However, this can sometimes cause the logic required for correct operation to be more complex, since, in the absence of immediate responses, there must be more controls to ensure that microservices are communicating with each other correctly.

​​​​Figure 2. Asynchronous communication between microservices.

Common strategies

Whether we have synchronous or asynchronous communication, designs for communication tend to follow certain common patterns. These tend to have certain characteristics that make development oriented towards one or the other type of communication.

For cases where synchronous communication is used, a common strategy for such communication between microservices is the use of API Gateway. This is a component that acts as an entry point for all client requests and then routes the requests to the corresponding microservices. This helps centralise security, scalability and monitoring logic, reducing complexity in individual microservices.

Communication designs often follow common patterns

On the other hand, another counter strategy is the implementation of Event-Driven Architecture for asynchronous communication. Using messaging systems such as Apache Kafka or RabbitMQ, in this strategy, microservices generate and consume events in the form of messages, allowing the sender to communicate efficiently with receivers without waiting for an immediate response.

It can be stated without a doubt that communication between microservices is a fundamental pillar of a microservices-based architecture. The choice of appropriate strategies and tools can determine the efficiency and robustness of the system is a key factor that requires thorough analysis before starting a project. Whether using synchronous or asynchronous communication, modern API testing tools or messaging platforms, it is essential to carefully consider how microservices interact to build applications.