How should Microservices Communicate?

Brian R. Cline
3 min readJan 4, 2022


Microservices are a popular architectural style for building applications composed of smaller, independent units of functionality. These units, or microservices, are designed to be loosely coupled and can be developed and deployed independently of one another. This modular approach to building applications has many benefits, including increased flexibility, scalability, and maintainability. The blog post What are Microservices? covers what microservices are in more detail.

A critical aspect of building a microservices-based application is how the microservices communicate with one another. In this post, we’ll explore some of the critical considerations for microservice communication and look at some of the most common approaches.

Communication Styles

There are a few different styles of communication that can be used by microservices:

  • Synchronous: In synchronous communication, a microservice sends a request to another microservice and waits for a response before continuing. This is a common approach when the calling microservice needs a specific piece of data or the results of a computation before it can proceed.
  • Asynchronous: In asynchronous communication, a microservice sends a request to another microservice and continues without waiting for a response. This approach can be useful when the calling microservice doesn’t need an immediate response or when the called microservice may take some time to process the request.
  • Event-driven: In event-driven communication, microservices communicate by publishing and subscribing to events. A microservice that needs to trigger an action in another microservice can publish an event, and the other microservice can subscribe to that event and take the appropriate action when it is triggered. This approach can be useful for decoupling microservices and enabling them to operate independently.

Communication Protocols

There are a number of different protocols that can be used for microservice communication, including:

  • HTTP: HTTP is a widely used protocol for communication on the web. It can be used for both synchronous and asynchronous communication between microservices.
  • REST: REST (Representational State Transfer) is an architectural style for building web services that use HTTP as the communication protocol. It is a common choice for microservice communication because it is simple, flexible, and well-supported by a wide range of tools and libraries.
  • gRPC: gRPC is a high-performance, open-source universal RPC framework developed by Google. It uses HTTP/2 as the underlying transport protocol and supports a variety of programming languages. gRPC can be used for both synchronous and asynchronous communication.
  • WebSockets: WebSockets is a protocol for full-duplex communication over a single TCP connection. It can be used for event-driven communication between microservices.

Other Considerations

There are a few other factors to consider when deciding how microservices should communicate:

  • Scalability: It’s important to choose a communication protocol and approach that can scale to meet the needs of your application. For example, if you expect a high volume of requests between microservices, you may want to consider using a protocol like gRPC or WebSockets, which can support high concurrency and low latency.
  • Security: Communication between microservices should be secure to protect sensitive data and prevent unauthorized access. Consider using secure communication protocols like HTTPS or SSL/TLS to encrypt data in transit.
  • Monitoring: It’s important to monitor the communication between microservices to ensure that it is functioning as expected. This can help you identify and troubleshoot any issues that may arise.

Wrapping it Up

Effective communication between microservices is crucial for building a successful, scalable, and maintainable application. There are three different ways communication styles can be used between microservices.

Originally published at Brian Cline.



Brian R. Cline

Dad, Husband, #Christian Enterprise Architect, #Salesforce, #Automation #JavaScript