Microservices Communication: Synchronous vs. Asynchronous Patterns

Quick Summary (TL;DR)

In a microservices architecture, services must communicate with each other. There are two primary communication patterns: Synchronous, where a service sends a request and waits for an immediate response, and Asynchronous, where a service sends a message without waiting for a reply. REST APIs and gRPC are common synchronous patterns. Message queues (like RabbitMQ or Kafka) are the standard for asynchronous communication. The choice between them is a critical architectural decision that impacts the resilience and coupling of your system.

Key Takeaways

• Synchronous Communication is Simple but Creates Coupling: When Service A calls Service B synchronously, it must wait for Service B to respond. If Service B is slow or unavailable, Service A is blocked. This creates temporal coupling between the services.
• Asynchronous Communication Increases Resilience and Decoupling: When Service A sends a message to a queue, it doesn’t need to know if Service B is running or how long it will take to process. This decouples the services and makes the system more resilient to failures.
• Use Synchronous for Queries, Asynchronous for Commands: A good rule of thumb is to use synchronous communication for read operations (queries) where a user is waiting for an immediate response. Use asynchronous communication for write operations (commands) or long-running tasks that can be processed in the background.

---

1. Synchronous Communication

In synchronous communication, the client sends a request and blocks, waiting until it receives a response from the server. This is a simple and familiar request-response model.

REST APIs

• What it is: An architectural style that uses standard HTTP verbs (GET, POST, PUT, DELETE) and status codes. It’s the most common style for building APIs on the web.
• Pros: Simple, well-understood, and uses standard HTTP, which is supported everywhere.
• Cons: Can be chatty, and performance can be an issue. Text-based JSON payloads are less efficient than binary formats.

gRPC

• What it is: A high-performance, open-source RPC (Remote Procedure Call) framework from Google. It uses Protocol Buffers (a binary format) for efficient serialization and runs over HTTP/2.
• Pros: Very high performance and low latency. Supports streaming communication. Strongly typed contracts.
• Cons: Less human-readable than JSON. Requires more specialized tooling.

2. Asynchronous Communication (Event-Driven)

In asynchronous communication, a service emits an event (a message) to a message broker without waiting for a response. Other services can then subscribe to these events and react to them.

Message Queues

• What it is: A message queue is an intermediary component that stores messages sent between services. A producer sends a message to the queue, and a consumer retrieves it for processing.
• Pros:
  • Decoupling: The producer and consumer are completely decoupled.
  • Resilience: If a consumer service is down, messages remain in the queue to be processed later.
  • Load Leveling: The queue can act as a buffer during traffic spikes, allowing consumers to process messages at their own pace.
• Cons: More complex to implement and debug. You need to manage a message broker. Eventual consistency must be handled.

Choosing the Right Pattern: An Example

Imagine an e-commerce application:

• Placing an Order (Asynchronous): When a user clicks “Place Order,” the Order Service could publish an OrderPlaced event to a message queue. The Payment Service and Shipping Service can then subscribe to this event and process the payment and shipment independently and in the background. The user gets an immediate response saying their order is being processed.

• Getting Order Status (Synchronous): When the user wants to check the status of their order, their client application would make a synchronous REST or gRPC call to the Order Service to query for the latest status and display it immediately.

By combining these patterns, you get the best of both worlds: a responsive user experience and a resilient, decoupled backend.

Common Questions

Q: What is eventual consistency? In an asynchronous system, there is a delay between when an event is published and when it is processed. This means the system is not instantly consistent. For example, immediately after placing an order, the shipping status might not be available yet. This state of being temporarily inconsistent but eventually correct is called eventual consistency.

Q: Can I use both REST and gRPC in the same system? Yes. It’s common to use gRPC for high-performance internal communication between services and to expose public-facing REST APIs for external clients and web browsers.

Tools & Resources

• gRPC: The official website for the gRPC framework.
• RabbitMQ: A popular, versatile open-source message broker.
• Apache Kafka: A powerful distributed event streaming platform often used as a message broker in event-driven architectures.

Related Topics

Microservices Architecture & Discovery

• An Introduction to Microservices Architecture
• A Guide to Service Discovery in a Microservices Architecture

API & Communication Patterns

• RESTful API Design Principles
• Async API Design Patterns
• gRPC API Development Best Practices
• Error Handling and Retry Mechanisms in APIs

Message Queues & Event-Driven Architecture

• Message Queue Patterns and Implementation
• Introduction to Message Queues for Asynchronous Communication
• Event-Driven Architecture Patterns

Distributed Systems & Consistency

• Distributed Database Consistency Patterns

Need Help With Implementation?

Choosing the right communication patterns is a critical decision in a microservices architecture. Built By Dakic provides expert consulting on system and microservices architecture, helping you design a communication strategy that is resilient, scalable, and right for your business needs. Get in touch for a free consultation.