Microservices Communication Visual Playbook
8 communication patterns used in modern microservices
Building a microservice is relatively easy.
Building multiple services that communicate efficiently, recover from failures gracefully, and continue scaling over time is where real system design begins.
There’s no universal communication pattern that works for every scenario. Some prioritize speed, some prioritize reliability, while others are designed to keep services independent as your architecture grows.
Understanding these patterns and knowing when not to use them will make you a much better backend or system design engineer.
Let’s walk through the eight patterns you’ll encounter most often in production systems.
1. Request / Response (REST over HTTP)
If you’ve built a web API, you’ve already used this pattern.
One service sends an HTTP request to another service and waits until it receives a response. It’s simple, predictable, and works perfectly when the caller needs an answer immediately.
Imagine an Order Service asking the Inventory Service whether an item is available. The order can’t continue until inventory responds, so synchronous communication makes sense.
The downside is that both services depend on each other being available at the same time. If Inventory becomes slow or unavailable, Order slows down too. As more services are chained together, latency increases and failures can quickly spread across the system.
REST is still the best choice for CRUD operations, user-facing APIs, and scenarios where an immediate response is required.
2. Remote Procedure Call (gRPC)
REST focuses on simplicity.
gRPC focuses on performance.
Instead of sending large JSON payloads, services exchange compact Protocol Buffer messages over HTTP/2. The result is lower latency, smaller payload sizes, and significantly better throughput.
This is why many large-scale backend platforms use gRPC for internal service-to-service communication.
It also introduces strong contracts through schemas, making it easier for teams to build reliable APIs.
The trade-off is complexity. Browser support is limited, debugging isn’t as straightforward as REST, and maintaining schemas requires discipline.
When performance matters more than human readability, gRPC is usually the better option.
3. Message Queue (Point-to-Point)
Not every task needs to happen immediately.
Sometimes the smartest thing a service can do is place work into a queue and move on.
Instead of waiting for another service to finish processing, the producer simply publishes a message. A worker consumes that message whenever resources become available.
Think about sending confirmation emails after an order is placed. The customer shouldn’t have to wait several seconds just because an email service is busy.
Queues improve reliability, smooth out traffic spikes, and make workloads much easier to scale.
The trade-off is that processing becomes asynchronous. Messages may arrive out of order, failed messages require retry strategies, and poison messages often need Dead Letter Queues (DLQs).
Whenever a task doesn’t require an immediate response, a queue is usually the better design.
4. Publish / Subscribe (Topics)
A queue delivers work to one consumer.
Publish/Subscribe delivers the same event to many consumers.
Imagine a customer placing an order.
That single event might trigger inventory updates, payment processing, analytics, email notifications, fraud detection, and recommendation engines - all independently.
The publisher doesn’t need to know who is listening. It simply publishes an event, and every interested service reacts.
This loose coupling makes systems easier to extend because new consumers can be added without modifying the producer.
The challenge comes later. Tracking where an event travels becomes harder, duplicate events must be handled safely, and debugging distributed event flows isn’t always simple.
Whenever one event should trigger multiple independent actions, Pub/Sub is usually the right choice.
5. Event-Driven Choreography
In choreography, there is no central controller.
Every service reacts to events and decides what to do next.
An Order Service publishes Order Placed.
The Payment Service notices the event and processes payment.
Once payment succeeds, it publishes Payment Completed.
The Shipping Service sees that event and starts delivery.
Each service only understands its own responsibility.
This creates highly independent systems where teams can build and deploy services without coordinating every change.
The downside is visibility.
As the number of events grows, understanding the complete business flow becomes increasingly difficult. Tracing failures across multiple services often requires excellent logging and distributed tracing.
Choreography works best when service autonomy is the highest priority.
6. Orchestration (Saga Pattern)
Sometimes business processes are simply too important to leave entirely to events.
Booking a flight, processing an online payment, or completing an e-commerce checkout often requires multiple services to succeed together.
That’s where orchestration comes in.
Instead of allowing services to react independently, an orchestrator coordinates every step.
It tells Payment to charge the customer.
Then it asks Inventory to reserve stock.
Finally, it requests Shipping to prepare delivery.
If one step fails, the orchestrator executes compensation actions to undo completed work.
This approach makes business workflows much easier to understand and monitor.
However, it also introduces a central dependency. If every decision flows through one orchestrator, that component can eventually become a bottleneck if not designed carefully.
Use orchestration whenever business consistency is more important than complete service independence.
7. Event Sourcing + CQRS
Most applications only store the latest state.
Event Sourcing stores every state change that ever happened.
Instead of recording that an account balance is $5000, the system stores every deposit, withdrawal, and transfer that produced that balance.
CQRS complements this by separating write operations from read operations.
Commands generate events.
Read models are built from those events and optimized for queries.
This architecture provides complete audit history, makes event replay possible, and scales read-heavy systems exceptionally well.
The price is additional complexity.
You’ll deal with eventual consistency, evolving event schemas, and a steeper learning curve than traditional CRUD applications.
It’s a pattern best suited for systems where historical data is just as valuable as the current state.
8. Service Mesh
As microservice platforms grow, communication itself becomes infrastructure.
Instead of every service implementing retries, authentication, encryption, traffic routing, and observability, those responsibilities move into sidecar proxies managed by a service mesh.
Applications simply communicate as usual.
The mesh handles everything else.
Features like mutual TLS, traffic splitting, retries, circuit breaking, and distributed tracing become platform capabilities rather than application code.
This dramatically reduces duplicated logic across services.
Of course, nothing comes free.
A service mesh introduces additional infrastructure, consumes more resources, and requires operational expertise to manage effectively.
For small systems, it is unnecessary.
For large Kubernetes platforms running hundreds of services, it quickly becomes indispensable.
Quick Summary:
The biggest mistake engineers make is trying to solve every communication problem with the same pattern.
Production systems rarely rely on just one approach.
A typical e-commerce platform might use REST for customer APIs, gRPC for internal services, queues for background jobs, Pub/Sub for notifications, Sagas for checkout workflows, Event Sourcing for financial records, and a Service Mesh to secure everything running in Kubernetes.
Great system design isn’t about memorizing patterns.
It’s about understanding the trade-offs behind each one—and choosing the simplest solution that solves the problem today while leaving room for tomorrow.
If you found this useful, follow Tech Fusionist for more visual guides on Cloud, DevOps, Kubernetes, AI, and System Design.
🔗 Linktree: https://linktr.ee/techfusionist
Happy learning! 🚀
~ Tech Fusionist