How do microservices communicate with each other?

Question

Accepted Answer

Services communicate either **synchronously** (request/response over REST or gRPC) or **asynchronously** (messages/events through a broker like Kafka or RabbitMQ).

## Synchronous (request/response)

The caller waits for a reply. Simple and intuitive, but it couples availability — if the callee is down, the caller is affected.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asynchronous (messaging/events)

The sender publishes a message and moves on; consumers process it later. This decouples services in time.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## When to use which

| Need | Choose |
|---|---|
| Immediate answer for the user | Synchronous |
| Decoupling, buffering, fan-out | Asynchronous |
| Strong temporal coupling OK | Synchronous |
| Resilience to downstream outages | Asynchronous |

## Pitfall

Long **synchronous chains** (A → B → C → D) multiply latency and failure probability. Prefer async or aggregation where possible.

## Why it matters

The communication style shapes the system's resilience: synchronous calls are easy to reason about but create tight runtime coupling, while async messaging buys decoupling at the cost of eventual consistency.

Most real systems mix both — sync for user-facing reads, async for background workflows.

Need	Choose
Immediate answer for the user	Synchronous
Decoupling, buffering, fan-out	Asynchronous
Strong temporal coupling OK	Synchronous
Resilience to downstream outages	Asynchronous