Como os microsserviços se comunicam uns com os outros?

Question

Accepted Answer

Os serviços se comunicam **sincronamente** (solicitação/resposta via REST ou gRPC) ou **assincronamente** (mensagens/eventos através de um broker como Kafka ou RabbitMQ).

## Síncrono (solicitação/resposta)

O chamador aguarda uma resposta. Simples e intuitivo, mas acopla a disponibilidade — se o chamado estiver inativo, o chamador é afetado.

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

## Assíncrono (mensagens/eventos)

O remetente publica uma mensagem e prossegue; consumidores a processam depois. Isso desacopla os serviços no tempo.

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

## Quando usar qual

| Necessidade | Escolha |
|---|---|
| Resposta imediata para o usuário | Síncrono |
| Desacoplamento, buffering, fan-out | Assíncrono |
| Acoplamento temporal forte OK | Síncrono |
| Resiliência contra falhas downstream | Assíncrono |

## Cilada

Cadeias **síncronas** longas (A → B → C → D) multiplicam latência e probabilidade de falha. Prefira async ou agregação quando possível.

## Por que isso importa

O estilo de comunicação molda a resiliência do sistema: chamadas síncronas são fáceis de raciocinar, mas criam acoplamento rígido em tempo de execução, enquanto mensagens assíncronas compram desacoplamento ao custo de consistência eventual.

A maioria dos sistemas reais mistura ambos — sync para leituras voltadas ao usuário, async para fluxos de trabalho em segundo plano.

Necessidade	Escolha
Resposta imediata para o usuário	Síncrono
Desacoplamento, buffering, fan-out	Assíncrono
Acoplamento temporal forte OK	Síncrono
Resiliência contra falhas downstream	Assíncrono