Quais são os compromissos entre comunicação síncrona e assíncrona?

Question

Accepted Answer

Comunicação **síncrona** bloqueia o chamador até uma resposta chegar; comunicação **assíncrona** envia uma mensagem e continua sem esperar. Cada uma faz diferentes compromissos em acoplamento, latência e resiliência.

## Comparação

| Aspecto | Síncrona (REST/gRPC) | Assíncrona (messaging) |
|---|---|---|
| Chamador espera? | Sim | Não |
| Acoplamento temporal | Forte | Fraco |
| Resiliência a interrupções | Baixa | Alta (broker em buffer) |
| Consistência | Imediata | Eventual |
| Complexidade | Menor | Maior |
| Debugabilidade | Mais fácil (linear) | Mais difícil (fluxos) |

## Visual

```text
SYNC:  Caller ──request──▶ Service
       Caller ◀─response── Service   (blocked the whole time)

ASYNC: Caller ──message──▶ [ Queue ] ──▶ Service
       Caller continues immediately; Service handles it later
```

## Regra prática

- Use **sync** quando o usuário precisa de uma resposta agora (por ex., carregar um perfil).
- Use **async** para trabalho em segundo plano, fan-out e para sobreviver a interrupções downstream (por ex., enviar um email de confirmação).

## Armadilha

Async esconde falhas — uma mensagem perdida ou tóxica pode quebrar silenciosamente um fluxo de trabalho. Você precisa de filas de letras mortas e monitoramento.

## Por que isso importa

A escolha controla diretamente como as falhas se propagam: chamadas síncronas falham rápida e visivelmente, mensagens assíncronas desacoplam mas adiam problemas para os consumidores.

Misturá-las bem — sync na borda, async para fluxos de trabalho — é uma habilidade fundamental na construção de microsserviços resilientes.

Chamador espera?	Sim	Não
Acoplamento temporal	Forte	Fraco
Resiliência a interrupções	Baixa	Alta (broker em buffer)
Consistência	Imediata	Eventual
Complexidade	Menor	Maior
Debugabilidade	Mais fácil (linear)	Mais difícil (fluxos)