Designing Inter-service Communication in a Microservice Architecture

Introduction

A microservice architecture comes with tons of advantages for large projects. They include agility, scalability, and performance because the problem domain is divided into smaller services that can be managed independently. This means the overall application or system has been broken down into cohesive and independent components or services. Each of these services is responsible for specific business capabilities or functions.

Oftentimes in this architectural style, there is a need to pass data from one service to one or more services to complete an operation. This is not something to worry about in a monolith architecture because all the operations are in the same system and communications are done internally, among different modules of the system.

Forms of inter-service communication

We can group the several types of inter-service communication into two forms:

• Synchronous

• Asynchronous

Synchronous Communication

In this type of communication, one service will communicate with another service using REST endpoints. The caller service will send a request and wait for the response from the callee. This type of communication is preferable when you need the response to continue your operation or when you need to ensure that the request you're sending is processed immediately.

The most commonly used synchronous communications are HTTP protocol and gRPC.

Pros

• It is easy to design.

• You can be sure to get an immediate response.

• Easy error handling.

Cons

• Increase in latency since one service has to wait for another service.

• The other service must be running at all times.

• The whole operation might fail if there's an error from the callee.

• Congestion management is challenging when the other service is busy.

Asynchronous Communication

Asynchronous communication allows the sender to continue with other operations without waiting for a response. It involves using a message broker to communicate among services. The sender publishes a message in the form of a queue or event and the receiver picks the message from the system. This type of communication requires less coupling between the services, as the sender doesn't need to know anything about the receiver, and vice versa.

The most commonly used asynchronous communications are Message Queues, Publish-Subscribe Systems, Event-Driven Architectures, and Message Brokers.

Pros:

• Multiple services that need the same data can retrieve it from the message infrastructure.

• Reduced latency as there's no waiting involved.

• The receiving service can process the task at its convenience when the server is available.

• Error handling can be handled at a central level on the broker.

Cons:

• This strategy introduces some level of complexity.

• There's a significant increase in the cost of managing the message infrastructure.

• It's not easy to move away or change your message infrastructure.

When and Where

There are no strict rules for selecting the type of communication channel for your project, but there are guidelines to help you make the decision.

• Use the synchronous form of communication if your service requires real-time processing and a response from the other service.

• Opt for the asynchronous form of communication if your data needs to be processed by multiple services, and you don't necessarily need to wait for their responses.