Microservices Communication Patterns

Microservices Communication Patterns

1. The API Gateway Pattern

An API Gateway acts as the single entry point for all client requests (web, mobile, third-party). Instead of clients calling dozens of individual microservices directly, they talk to the gateway.

Key Responsibilities:

  • Routing (Reverse Proxy): It takes the incoming request URL and routes it to the correct downstream microservice (e.g., /api/v1/users $\rightarrow$ User Service).

  • Authentication & Authorization: The gateway handles token validation (like JWTs), OAuth, or API keys before the request hits your internal network. This saves you from rewriting auth logic in every single microservice.

  • Rate Limiting & Throttling: It protects your backend from being overwhelmed (or hit by DDoS attacks) by limiting how many requests a user or IP can make per second.

💡 Popular Tools: Kong, AWS API Gateway, NGINX, Envoy, Traefik.

2. Service-to-Service Communication

Once a request passes the gateway, how do internal microservices talk to each other? There are three dominant paradigms:

REST (Representational State Transfer)

  • How it works: Standard HTTP/1.1 or HTTP/2 using JSON payloads. It’s synchronous and resource-oriented.

  • Best for: Public APIs, frontend-to-backend communication, and standard, low-complexity internal calls.

  • Pros/Cons: Highly compatible and easy to debug, but JSON payload serialization can be slow and verbose for heavy internal traffic.

gRPC (Google Remote Procedure Call)

  • How it works: Built on HTTP/2 and uses Protocol Buffers (Protobuf) instead of JSON. It treats remote service methods as if they were local functions.

  • Best for: High-performance, low-latency internal service-to-service communication.

  • Pros/Cons: Blazing fast, strictly typed, and supports streaming. However, it’s harder to debug (binary format) and has poorer browser support.

GraphQL Federation

  • How it works: Instead of a monolithic GraphQL server, multiple microservices expose their own GraphQL schemas, which are combined (federated) into a single, unified graph gateway.

  • Best for: Complex data aggregation where the frontend needs data from multiple services in a single query.

  • Pros/Cons: Eliminates over-fetching/under-fetching of data. However, it introduces significant setup complexity and potential performance bottlenecks if queries aren’t optimized.

3. Event-Driven Architecture (EDA)

In contrast to synchronous calls (where Service A waits for Service B to respond), EDA relies on asynchronous communication. Services communicate by producing and consuming events.

Pub/Sub (Publish/Subscribe)

A pattern where a sender (Publisher) broadcasts a message without knowing who the receivers (Subscribers) are. A central broker handles the distribution.

Choosing a Broker: Kafka vs. SQS/SNS

The choice of message broker depends heavily on your data retention and ordering needs:

Feature Apache Kafka AWS SNS / SQS
Type Distributed Log / Event Streaming Managed Message Queue (SQS) & Topic (SNS)
Data Retention Persistent (acts as a database; messages can be replayed) Ephemeral (deleted after consumption/expiry)
Scale High-throughput, massive scale Scale-on-demand, serverless
Best Used For Event sourcing, real-time analytics, high-volume telemetry Simple task queues, decoupled notifications, standard app workflows

4. Saga Patterns: Choreography vs. Orchestration

When a business transaction spans multiple microservices (e.g., placing an order, charging a card, and updating inventory), you need a way to manage the workflow. This is called the Saga Pattern.

[Image comparing choreography vs orchestration in microservices saga pattern]

Choreography (Decentralized)

  • The Concept: There is no central boss. Services listen to events and react independently.

  • Example: Order Service emits OrderCreated. Payment Service hears it, charges the card, and emits PaymentSuccessful. Inventory Service hears that and updates stock.

  • Pros: Highly decoupled, no single point of failure.

  • Cons: Hard to understand the entire workflow at a glance; risk of cyclic dependencies.

Orchestration (Centralized)

  • The Concept: A central brain (an Orchestrator) directs the flow, telling each service exactly what to do and when.

  • Example: The Order Orchestrator calls Payment Service $\rightarrow$ waits for response $\rightarrow$ calls Inventory Service $\rightarrow$ finishes transaction.

  • Pros: Easy to track the state of a transaction, built-in support for complex conditional logic and rollbacks (compensating transactions).

  • Cons: The orchestrator can become a single point of failure or a “god object” containing too much business logic.