Communication Over Microservices

Proper choice of the communication protocol over Microservices makes the application more responsive and efficient. Various aspects need to be
considered regarding communication before breaking down into services.

There are 2.5 quintillion bytes of data generated every day. Software built
using monolithic architecture may face problems like difficulties in scaling, longer time to ship, spaghetti code, etc.

Microservice architecture has become the de facto choice for modern application development. As the name suggests, Microservice architecture is an approach to building a server application as a set of small services.

With the wide adoption of trending architecture, there are lots of challenges to deal with small service as it doesn’t suggest common standards and patterns. The implementation depends on team maturity and business requirements. Architecture becomes more mature and independent as the team faces the problems over time.

As the services get deployed independently, it requires an efficient protocol to communicate between the services. Improper use of the
communication protocol may lead to poor performance in applications.

Communication Protocol

There are two styles of communication: synchronous and asynchronous. These are the foundations for the request-response and the event-driven patterns.

Synchronous Protocol

The client requests service and waits for the response. The synchronous protocol is blocking, i-e CPU waits for the response. HTTP is a type of synchronous communication. Modern web applications follow the RESTful
architectural style to build APIs for inter-process communication. REST treats every object or entity as a service resource that is accessed by using the HTTP verbs.

Generally, the data are exchanged between services in the JSON format. HTTP verbs are used to manipulate the resources in the server. A post request creates the new resource and a put request updates a resource.

While accessing resources from the microservices, it assumes to get a response in a short period. A client that requires the real-time update on the user interface uses the synchronous protocol. The application developer uses the interface definition language to build services. There are few options such as Swagger, RAML which are widely used.

Asynchronous Protocol

Synchronous communication between the microservices lags in performance. Microservices may form a chain of requests between services to respond to a single client. Asynchronous communication is recommended over the synchronous to be a resilient microservices. The asynchronous protocol is non-blocking in nature.

If services form the chain of request over microservices it increases the communication overhead which leads to poor performance. It follows the event-driven architecture, there may be one to one and one to many mapping between event producer and consumer.

Single Receiver

Each request has one sender and one receiver. In the case of multiple requests, they get queued because of the single receiver which can consume one at a time.

Multiple Receiver

Each request can be processed by zero to multiple receivers. This is
based upon the event-bus interface or message broker while exchanging data between the microservices through events.

Publish-subscriber Pattern

When any events occur in the services it may need to communicate with other services to complete the job. Publisher and subscriber model is an asynchronous pattern which reduces the coupling in the distributed system.

Publisher

The publisher doesn’t need the subscriber to be up and available. It sends a message to the message queue. Nor does the publisher need to know about the subscriber application that needs to receive the message. Once the message is published in the specific topic the message gets broadcast in the channel to notify the subscribers. Subscribers consume the message in the queue.

Subscriber

The subscriber subscribes to a particular topic to get notified once the message is published in the respective topic. There may be many subscribers as client request grows.

Input Channel

Channel used by the publisher to send message to the subscriber.

Output Channel

Channel used by the subscriber to consume the message.

Message Broker

Message from the publisher is copied from the input channel to the output channel of interested subscribers, this mechanism is handled by the message broker. All these events occur asynchronously. There are many message broker and third-party services to facilitate the publish/subscribe protocol.

Among them, RabbitMQ, Amazon SQS, Redis, Apache Kafka, Amazon SQS, Google Cloud Pub/Sub are used widely.

Choosing Message Broker

Choosing a message broker as per business requirements is the crucial portion of service communication. There are various parameters for choosing the right message broker.

Broker Scale: The number of messages sent per second in the system

Data Persistency: The ability to recover messages

Consumer capability: The broker capability to deal with one to one and one to many

Comparisons Between Message Broker

RabbitMQ

It provides the flexibility to send messages up-to 50k per second. Message
brokers can be configurable to both transient and persistent. The subscriber can be both one or many as per need. It follows the Advanced message queuing protocols. RabbitMQ is best suited for complex routing.
General programming languages are supported.

Kafka

Kafka is an open-source stream-processing software platform developed by LinkedIn. It has high-throughput, low latency for handling real-time data feeds. It provides the data persistency as well and supports one to many subscribers only. It is best to fit to play with large amounts of data.

Redis

Redis is an in-memory data structure project implementing a distributed, in-memory key-value database with optional durability. It can send up to a million messages per second. It is best suited for the use case of short message retention and where persistence doesn’t matter. It supports one to many subscribers and provides extremely fast service.

Design Pattern Based upon Communication

ORCHESTRATION

In orchestration, there is a single orchestrator that acts as a coordinator to send responses for clients. Orchestrator synchronously manages all services to serve clients. In this pattern, services are tightly coupled to each other. Once the coordinator goes down there will be a single point of failure. As all services communicate synchronously, the time to send response grows as the interaction between services increases.

CHOREOGRAPHY

Central orchestrator creates the dependencies within the microservices. In microservice, each service should be able to stand on its own. Choreography solves some of the problems of orchestrators. It enables faster processing as it can execute parallel/asynchronously. Services can be plugged as the user grows because the publisher doesn’t have to be aware of the subscriber.

Direct client to microservice communication approaches each microservice
has a public endpoint. The client directly consumes the endpoint of services in the production environment. Most of the time these services have communication by means of Advanced messaging queue, gRPC,unlike HTTP protocol. Clients may not be able to have communication with services in that scenario.

Clients also get coupled tightly with the services. Clients have to make too many requests to render a single user interface as all the services are broken into small manageable pieces. Clients will not be able to handle the cross-cutting concerns such as authorization, data transformations, and dynamic request dispatching.

API Gateway

API gateway is a hybrid approach to both orchestrator and choreography.
While designing the large or complex microservice-based application having multiple client apps like Android, iOS, and Single Page Applications, etc, API Gateway is a better approach to deal with. It is similar to the Facade pattern from object-oriented design. It provides the abstraction of the internal communication of microservices as it is tailored to each client. It might have other responsibilities such as authentication, monitoring, load balancing, caching, request shaping, and static response handling.

It provides a single entry point for a group of services. As it is the single entry point for every client app there will be a single point of failure. To deal with that problem API gateway can be segregated to handle clients as per business requirements. It also has many drawbacks like a possible single point of failure, tightly coupling between internal microservice. API gateway may become a bottleneck if it has not configured for scaling.

Conclusion

The synchronous communication protocol may form a chain of requests
while sending a response to the client, which may lead to bad user experience and a single point of failure. Asynchronous communication is
preferred over the synchronous which will be more responsive and fault-tolerant. While building applications, proper architecture plays an important role to make applications more robust, fault-tolerant, and scalable.

Each architecture has its pros and cons. If the microservices have to serve multiple clients then API Gateway pattern can be best matched but to ome extent only. Proper architecture decisions as per business requirements and best communication protocol between the microservices may lead to better performance, scalability, and fault-tolerant projects.

References

• https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
• https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
• https://medium.com/capital-one-tech/microservices-when-to-react-vs-orchestrate-c6b18308a14c
• https://medium.com/capital-one-tech/microservices-when-to-react-vs-orchestrate-c6b18308a14c
• https://dzone.com/articles/patterns-for-microservices-sync-vs-async
• https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture
• https://dzone.com/articles/design-patterns-for-microservice-communication
• https://martinfowler.com/articles/microservices.html
• http://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html
• https://dzone.com/articles/building-microservices-inter-process-communication-2
• https://otonomo.io/blog/redis-kafka-or-rabbitmq-which-microservices-message-broker-to-choose/
• https://www.youtube.com/watch?v=4KQoYVX9lNM
• https://www.youtube.com/watch?v=rXi5CLjIQ9k

Previously published at https://medium.com/@rajesh_khadka/communication-over-micro-services-49a8b1586969