As you know, in the microservice architecture, each service is isolated from other services. To communicate from one service to one or more other services, we need to know about the communication mechanisms. In this article series, we will discuss about most common microservice communication mechanisms. Lets start our learning journey.

Microservice communication mechanisms can be divided into two categories.

1. Synchronous communication

• Client service sends the request to one or more services and wait for the response(s) from that services.
• Use HTTP(HTTPS as well), gRPC protocols for communication.
• Client blocks the thread. When it receives the response the rest of the code will continue.

2. Asynchronous communication

• Client service sends the request to one or more services and it does not wait for the response(s) from that services.
• Use AMQP protocol.
• Using AMQP protocol clients send the message with help of message broker systems like Kafka, RabbitMQ.
• Messages consume from subscriber systems in async way and it does not wait for quick response.
• AC can be divided into 2 categories.
  • One to One (Queue)
  • One to Many (Topic)

In this part, we will be more focused on synchronous communication.

Different types of communication patterns.

1. Request/Response communication.

• When service A sends a request to service B, service A always wait for service Bs response.
• For synchronous request/response communication - use HTTP and REST protocols
• Uses to expose APIs from microservices.
• If the communication between internal microservicers - use gRPC protocol. gRPC provides high performance and low latency.
• If you need to define the structure of data - use GraphQL. -
• GraphQL provides 1 response per request in a more flexible and efficient way.

Ex:- REST communications, GraphQL, gRPC etc...

2. Pull communication.

• A service request data from another service only when it needs. This is also know as polling.

Ex:- An Order processing service pull current product data from inventory service to check the availability.

• Based on HTTP, AMQP (short polling - long polling)
• It’s a call-and-ask model. (also called “Polling”)
• It is basically the same as refreshing your email every 5 minutes to check for new mail.
• Drawback.
  • waste of bandwidth (if there is no new mail and a response comes from the server.)
  • Opening and closing connections is expensive. The model does not scale well.
• Generally, we can poll an API at any time. But some applications limit API calls.

Polling can be divided into two categories.

1. Short polling - In short polling, the client sends requests frequently to the server to check for new update or data. Server responses to the each request even there is no any updates.

Ex:- Real-time dashboards, servers' health checks.

1. Long polling - The client send one request and server holds it until new data is arrived.

Ex:- Notification service

3. Push communication.

• A service keep sends data to another service without asking it.
• Based on the HTTP, Websocket protocol.
• Use for real-time two-way one-to-many communication like chat applications.
• Here, clients and servers can both send messages to each other at any time.

Ex:- A user service push updates to an email service to trigger email about user updates.

4. Event driven communication.

• Asynchronous messaging pattern that use publishers and subscribers.
• These microservices don’t call each other. They create and consume events in an async way through a message broker system (RabbitMQ and Kafka queues).
• Use Publish/Subscribe pattern. Benefits
  • Producer service does not know about its consumer service. Consumer services don't necessarily know about the producer. So, services can be deployed independently. So it’s a loosely coupled microservice. Drawbacks
  • No clear central place or orchestrator; this increases the complexity of architecture.

Synchronous communication.

As I briefly explained above, when a service communicate with another service by requesting some data and it waits for the response (with requested data), it is a synchronous communication.

Lets take user login scenario as an example. First a user send a request with his email and password. Then client application sends these data to backend service and wait until its acknowledgement. If those input are valid user can log in.
This is a REST based communication mechanism. There are more synchronous communication ways that we will discuss in this article.

• These microservices don’t call each other. They create and consume events in an async way through a message broker system (RabbitMQ and Kafka queues).
• Use Publish/Subscribe pattern.
• Benefits
  • Producer service does not know about its consumer service. Consumer services don't necessarily know about the producer. So, services can be deployed independently. So it’s a loosely coupled microservice.
• Drawbacks
  • No clear central place or orchestrator; this increases the complexity of architecture.

Synchronous communication and best practices

• In synchronous communication, clients send a request and wait for a response.
• Communication protocols can be HTTP or HTTPS. should follow the HTTP/REST protocol (can be extended with gRPC and GraphQL).

Different types of synchronous communication methods

• In this section, I will be discussing briefly some popular synchronous communication methods.
• I will discuss each of this method deathly in my future articles.

1. RESTful applications.

• Applications that use HTTP/REST for communication.
• There are some rules to define RESTful APIs as below.
• You can refer @ksound22 REST API Best Practices – REST Endpoint Design Examples for better patterns.
• Benefits
  • Requests can simply be sent using browsers.
  • HTTP protocol
  • HTTP GET has organic (built-in) caching options.
  • JSON representative request-responses
  • Provide better scalability.
• Drawbacks
  • Send multiple requests to get relational data.
  • Chatty communication when enriching data.
  • Over-fetching (providing additional information that is not required) and under-fetching requests are hard to implement and require multiple calls.

2. GraphQL

• It is a query and manipulation language. It allows us to define the structure of the required data.
• It provides access to many sources with a single request. So it reduces the number of multiple network calls.
• Core concepts
  • Schemas - Describe all the possible data that clients can query on it.
  • Resolvers - Those are the functions that attach to fields in a schema. During executions, resolvers call to produce the values.
  • Mutation - GraphQL operations (allowing the insert of new data and modification of existing data)
• Benefits
• Can get exactly what you need.
• Can get many resources in a single request.
• Evolve APIs without versioning.
• Fast and quick response time (because it reduces the number of calls to get data)
• Strongly typed (define types before querying). It reduces miscommunication.)
• More flexible with schema and type systems
• Drawbacks
  • Query complexity. When accessing multiple fields in a single query, it may request too much-nested field data at a time. This causes performance problems)
  • Caching (complicated to implement a simple cache in GQL when compared to REST)
  • Rate Limit. (It is difficult to allow a specific number of requests at a specific time.)

Issues with both REST and GraphQL

• Network performance issues affect inter-service communication.
• Backend communication performance requirements
• Real-time communication requirements
• Streaming requirements.

3. gRPC - Google Remote Procedure Calls

• There are two kinds of APIs.
• Public APIs - User HTTP REST. APIs should be human-readable.
• Backend APIs - Use gRPC. The Importance of backend APIs is network performance instead of human readability.
• gRPC is used to communicate between services, efficiently and independently in their preferred languages.
• Focused on high performance. For that, it uses the HTTP/2 protocol to transport binary messages.
  • HTTP/1 opens HTTP calls for a request. (HTTP/2 provides long lasting connection)
  • HTTP/1.1 does not compress headers. (HTTP/2 compresses the headers and data to the binary format.)
  • Only accept request response patterns.(HTTP/2 support server push. That means the client can send multiple messages from one request to the server. - streaming) - Less chatter EX:- In HTTP/1.1 Clients have to send 3 requests to access 3 assets and have to get three responses from that request. In
  • HTTP/2 clients can send requests inside one TCP connection and wait for one response from the server.
  • HTTP/2 supports multiplexing ( Server and client send multiple messages in parallel over the same TCP connection.)
• It uses Protocol Buffers (Protobuf) for service-to-service communication.
• Messages are smaller than JSON.
• Passing JSON is more CPU intensive. (Because the format is human readable.)
• Protobuf provides more security than JSON because it’s not human readable, easy to install SSL for client and server.
• Benefits
  • Provide 30-40% more performance when compared to REST because of HTTP/2 protocol.
  • gRPC uses binary serialization, which also provides higher Performance and less bandwidth compared to JSON.
  • Support multiple languages and platforms.
  • Support for bi-directional streaming.
  • Support SSL/TLS usage.
  • Support many authentication methods.
• Usages
  • Synchronous microservice to microservice communication. Polyglot environments that need to support mixed programming languages.
  • Low latency and high throughput communication where performance is critical.
  • Point-to-point real-time communication. (push messages in real-time and are required to support bi-directional streaming.)
  • The network-constrained environment requires less bandwidth usage. (Binary gRPC messages are always smaller than text-based JSON)

4. WebSocket (ws:// , wss://)

• A websocket uses for real-time two way communications between client and server. (Ex:- chat with an agent.)
• Send messages to the server and receive event based communication without having polling.
• Provide bidirectional protocol for same client server communications.
• Stateful protocol - Until terminating the connection from one party, communication stays alive.
• Use Cases
  • For real-time application development. (Stock market/ Crypto currency prices changing)
  • Online gaming applications
  • Chat applications

5. Webhooks

• For the simple understand, a webhook is just a POST request that is used to push messages/events between two services.
• Uses HTTP protocol to communicate with applications.
• Usages
  • Get real-time notifications/data from external services.
  • To trigger scheduled actions.
  • Sync data between different systems.
• Benefits
  • Best way to get real-time updates.
  • Easy to integrate with an application.
  • Efficient and reduce the latency.
• Drawback
  • Issue with delivery reliability
  • Security issue (Can be affect to DDOS easily)

So, through this article, I have discussed what the microservice communication methods are and what the synchronous communication patterns are. If you have any questions regarding this article please let me know by commenting. I will hope to discuss synchronous communication more deeply in the upcoming articles. So stay tuned with me.