Microservice Architecture Communication Design Patterns

Microservice architecture aims to decompose an application into loosely coupled services organized around business capabilities, but splitting a monolith introduces cross‑service transaction challenges that must respect the CAP theorem and distributed computing constraints.

When a single business operation spans multiple services, communication—both synchronous (request‑response) and asynchronous (message‑driven)—becomes essential. Synchronous calls require both parties to be up, while asynchronous messaging enables loose coupling, fault tolerance, and scalability using protocols such as MQTT, STOMP, and AMQP, often backed by platforms like Apache Kafka, RabbitMQ, or ActiveMQ.

1

Coordinating Service Communication

Different environments may use synchronous request‑response (REST, GraphQL, gRPC) or asynchronous messaging, each with trade‑offs regarding latency, reliability, and coupling.

2

Messages and Events

Messages encapsulate intent and are routed via queues; events represent state changes and are consumed by listeners. Domain events (e.g., OrderRequested) differ from change events generated by databases.

3

Smart Endpoints and Dumb Pipes

Following Martin Fowler’s principle, microservices should contain business logic (smart endpoints) while the communication layer remains simple (dumb pipe), avoiding heavyweight ESBs.

4

Asynchronous Communication Protocols

MQTT – lightweight publish/subscribe protocol widely used in IoT.

AMQP – open standard for message‑oriented middleware.

STOMP – simple text‑based protocol over HTTP.

5

General Messaging / Streaming Platforms

ActiveMQ

Kafka

RabbitMQ

Redis Streams

Evaluation criteria include availability, durability, scalability, and consumer throughput.

6

Microservice Design Patterns

Patterns address autonomy, scalability, low coupling, and fault tolerance, providing reusable solutions for common architectural challenges.

7

Saga Pattern – Maintaining Atomicity Across Services

A saga consists of a series of local transactions that publish messages or events to trigger the next step; compensating transactions roll back changes when a failure occurs. Sagas can be choreography‑based (event‑driven) or orchestration‑based (central controller).

8

Two‑Phase Commit

Two‑phase commit separates preparation and commit phases but suffers from performance and reliability issues in distributed environments, making it unsuitable for most microservice use cases.

9

Event Sourcing – An Alternative Persistence Strategy

Instead of overwriting state, event sourcing stores each state change as an immutable event, allowing reconstruction of any point‑in‑time state and providing audit trails, time‑travel queries, and high performance.

10

CQRS – Command Query Responsibility Segregation

CQRS separates write (command) models from read (query) models, enabling independent scaling, optimized data stores, and better performance for complex domain models.

11

Outbox Pattern

The outbox table stores events alongside primary data changes within the same transaction; a message relay reads the outbox and forwards messages, ensuring reliable state propagation.

12

Change Data Capture (CDC)

CDC streams database changes (via log‑based or query‑based methods) to downstream systems, often using connectors like Debezium to feed Kafka topics.

13

Idempotent Transactions

Idempotency ensures that repeated identical requests have the same effect as a single request; essential for REST GET operations and for handling at‑least‑once delivery in message brokers.

14

Final Consistency

Distributed systems often relax strong consistency in favor of availability, adopting BASE principles and eventual consistency models, as illustrated by CAP trade‑offs.

15

Distributed Tracing

Tracing propagates a unique transaction ID across service boundaries, enabling end‑to‑end latency analysis, fault isolation, and dependency mapping; tools include OpenTracing, Jaeger, Zipkin, and AppDash.

16

Service Mesh

A service mesh (e.g., Envoy, Istio) provides load balancing, service discovery, health checks, and security for microservice communication, abstracting these concerns from application code.

Original source: https://medium.com/dev-genius/microservice-architecture-communication-design-patterns-70b37beec294