Microservices are independent services that need to exchange data to work together. How they communicate determines the system’s scalability, resilience, and latency characteristics.
TL;DR Microservices communicate in two fundamental styles: synchronous (one service calls another and waits for a response — REST, gRPC) and asynchronous (one service publishes a message and doesn’t wait — message queues, event streaming). Synchronous is simpler to implement and reason about but creates coupling and cascading failures. Asynchronous improves resilience and decoupling but adds complexity. Most production architectures use both: synchronous for user-facing requests that need immediate responses, asynchronous for background processing, notifications, and inter-service events.
The two communication styles
Synchronous communication
Service A calls Service B and waits for the response before continuing. The caller is blocked during the request.
User Request → Service A → (blocks waiting) → Service B → response → Service A → response → UserCharacteristics:
- Simple request-response pattern
- Caller knows immediately if the request succeeded or failed
- If Service B is slow or down, Service A is blocked (and potentially times out)
- Tight temporal coupling — both services must be available simultaneously
Protocols: REST over HTTP, gRPC, GraphQL, SOAP
Asynchronous communication
Service A publishes a message and continues immediately without waiting. Service B processes the message at its own pace.
Service A → publishes message → Message Broker → Service B processes (later)Characteristics:
- Publisher and consumer are decoupled in time — consumer can be offline
- Higher resilience — if Service B is down, messages queue up and process when it recovers
- No immediate confirmation of processing success
- Harder to trace end-to-end flow
Protocols: Message queues (RabbitMQ, SQS, ActiveMQ), event streaming (Kafka, Kinesis)
Synchronous protocols
REST (HTTP)
REST is the most common synchronous protocol. Services expose HTTP endpoints; callers make GET, POST, PUT, DELETE requests and receive JSON responses.
Strengths: Human-readable, widely supported, easy to debug, language-agnostic. Weaknesses: Verbose (JSON overhead), no strong contract, HTTP/1.1 has one-request-per-connection limitations.
Best for: Public APIs, user-facing services, CRUD operations, services consumed by web/mobile clients.
gRPC
gRPC uses Protocol Buffers (binary serialization) and HTTP/2. It generates strongly-typed client and server code from a .proto schema definition.
service OrderService { rpc GetOrder (OrderRequest) returns (OrderResponse); rpc StreamOrders (OrderRequest) returns (stream OrderResponse);}Strengths: 5–10× more efficient than REST/JSON, strong contract (schema-first), bidirectional streaming, auto-generated clients. Weaknesses: Not human-readable, harder to debug without tooling, poor browser support (requires gRPC-Web).
Best for: Internal service-to-service calls, high-throughput services, services that need streaming.
GraphQL
GraphQL lets clients specify exactly what data they need in a single request. One endpoint serves all queries.
Strengths: Eliminates over-fetching and under-fetching, flexible queries, strongly typed schema. Weaknesses: Complex caching, N+1 query problem, overkill for simple CRUD.
Best for: Aggregator services, APIs consumed by multiple client types with different data needs.
Asynchronous patterns
Message queues
A message queue stores messages until a consumer retrieves and processes them. Each message is typically processed by one consumer (point-to-point).
Order Service → [Order Created message] → Queue → Payment Service (one consumer)Use cases: Order processing, email sending, background jobs, offloading slow operations from the request path.
Examples: RabbitMQ, Amazon SQS, Azure Service Bus.
Event streaming
In event streaming, services publish events to a log (the stream). Multiple consumers can independently read and replay events — each at their own offset.
Order Service → [Order Created event] → Kafka Topic → Payment Service → Inventory Service → Analytics ServiceEvents persist in the log for a configurable retention period (days to forever), enabling replay and new consumers to catch up from the beginning.
Use cases: Real-time analytics, event sourcing, audit logs, fan-out to multiple consumers.
Examples: Apache Kafka, Amazon Kinesis, Confluent Cloud.
Event-driven architecture
In event-driven systems, services react to events published by other services. Services are fully decoupled — they don’t know who is listening.
Choreography: Each service listens for events and reacts independently. No central coordinator.
Order Service publishes → Order CreatedPayment Service listens → charges card → publishes Payment ConfirmedInventory Service listens → reserves stock → publishes Stock ReservedOrchestration: A central orchestrator tells each service what to do in sequence.
Order Orchestrator → calls Payment Service → calls Inventory Service → calls Shipping ServiceChoosing synchronous vs asynchronous
| Scenario | Recommended style | Reason |
|---|---|---|
| User makes a request and needs an immediate answer | Synchronous (REST/gRPC) | User is waiting for a response |
| Sending a confirmation email after sign-up | Asynchronous (message queue) | Email can be sent in the background; user doesn’t need to wait |
| Processing a payment | Synchronous | Immediate feedback required |
| Updating downstream analytics systems | Asynchronous (event streaming) | Analytics don’t need real-time consistency |
| Notifying multiple services about a new order | Asynchronous (event streaming) | Fan-out to multiple consumers efficiently |
| Fetching inventory count for a product page | Synchronous | Real-time data required for the page |
Service discovery
In microservices, service instances are dynamic — they scale up and down, and their IP addresses change. Service discovery lets services find each other without hardcoded addresses.
Client-side discovery: The calling service queries a service registry (Consul, Eureka) to find available instances, then load-balances requests itself.
Server-side discovery: Requests go to a load balancer or API gateway, which queries the registry and routes appropriately.
DNS-based discovery: Services register with DNS; callers resolve the service name to an IP. Simple but limited in sophistication.
API gateway pattern
An API gateway is a single entry point that handles all external requests and routes them to the appropriate microservice. It centralizes:
- Authentication and authorization
- Rate limiting
- SSL termination
- Request routing and load balancing
- Response aggregation (combining responses from multiple services)
Without an API gateway, clients must know about all individual services and manage authentication, retries, and routing themselves.
Handling failures
Microservices introduce distributed systems problems. Key patterns for resilience:
| Pattern | What it does |
|---|---|
| Circuit breaker | Stops calling a failing service after N errors, preventing cascading failures |
| Retry with backoff | Retries failed requests with increasing delays to avoid overwhelming a struggling service |
| Timeout | Sets a maximum wait time — if a service doesn’t respond, fail fast rather than blocking indefinitely |
| Bulkhead | Isolates resources per service — a failing service consumes only its allocated thread pool, not all resources |
| Dead letter queue | Failed messages go to a separate queue for inspection rather than being lost |
Frequently asked questions
How do microservices communicate with each other? Microservices communicate using synchronous protocols (REST over HTTP or gRPC) where one service calls another and waits for a response, or asynchronous messaging (message queues or event streams) where one service publishes a message without waiting. Most architectures use both — synchronous for user-facing requests, asynchronous for background processing.
What is the difference between REST and gRPC in microservices? REST uses HTTP and JSON — human-readable, widely supported, easy to debug. gRPC uses HTTP/2 and Protocol Buffers (binary) — 5–10× more efficient, strongly typed with auto-generated clients, supports streaming. REST is preferred for external/public APIs and simpler services. gRPC is preferred for high-throughput internal service-to-service calls.
What is asynchronous communication in microservices? Asynchronous communication means a service publishes a message (to a queue or event stream) and continues without waiting for another service to process it. This decouples services in time — the consumer can be offline, slow, or process messages in batches. It improves resilience but makes it harder to trace errors and reason about consistency.
What is a message queue in microservices? A message queue is an intermediary that stores messages between a producer (sender) and a consumer (receiver). The producer sends messages without knowing if the consumer is ready. The consumer processes messages when it’s available. Each message is typically delivered to one consumer. Examples: RabbitMQ, Amazon SQS.
What is event streaming vs message queues? Message queues deliver each message to one consumer (point-to-point) and delete it after processing. Event streaming (Kafka, Kinesis) persists events in a log, and multiple independent consumers can read and replay events at their own pace. Use message queues for task processing; use event streaming for analytics, audit logs, and fan-out to multiple consumers.
What is a service mesh in microservices? A service mesh (Istio, Linkerd) is an infrastructure layer that handles service-to-service communication transparently — providing load balancing, circuit breaking, retries, observability, and mTLS encryption between services without requiring changes to application code. It intercepts traffic via sidecar proxies running alongside each service.
What is the difference between choreography and orchestration in microservices? In choreography, each service reacts to events and publishes its own events — no central coordinator. In orchestration, a central orchestrator service explicitly calls each service in sequence and manages the workflow. Choreography is more decoupled but harder to trace. Orchestration is easier to understand and debug but creates a central point of coupling.
How do microservices handle authentication? Typically via JWT (JSON Web Tokens) validated at the API gateway. The gateway authenticates the incoming request, then propagates the user identity (as a JWT or request header) to downstream services. Services trust the gateway’s authentication and focus on authorization — checking whether the authenticated user has permission to perform the requested action.