System Design/04 - Cloud Design Patterns/Messaging2 min
Choreography
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Cada serviço reage a eventos e emite os seus, sem um coordenador central. O fluxo emerge das reações encadeadas.
Pedidos ──PedidoCriado──→ Pagamento ──PagamentoAprovado──→ Estoque
──→ Logística
Ninguém "comanda" o fluxo. Cada serviço conhece apenas os eventos que consome e os que produz.
Coreografia vs orquestração
| Coreografia | Orquestração | |
|---|---|---|
| Controle | Distribuído | Central (Scheduler Agent Supervisor, Step Functions) |
| Acoplamento | Baixo | Maior (o orquestrador conhece todos) |
| Fluxo visível | Não — emerge | Sim — declarado num lugar |
| Adicionar passo | Nova inscrição | Alterar o orquestrador |
| Depurar | Difícil | Mais fácil |
| Compensação em falha | Cada um por si | Centralizada |
Trade-offs
A coreografia entrega acoplamento baixo e evolutividade: um novo consumidor entra sem tocar em ninguém.
O preço é que ninguém sabe qual é o fluxo. Não existe um artefato que descreva o processo de ponta a ponta; ele está espalhado entre inscrições. Responder "o que acontece quando um pedido é criado" exige ler todos os serviços — e a resposta muda quando alguém adiciona uma inscrição.
Isso fica pior quando o processo precisa de compensação. Se o pagamento foi aprovado e o estoque falhou, quem estorna? Na coreografia, cada serviço precisa reagir a eventos de falha e desfazer sua parte (Compensating Transaction) — uma lógica distribuída difícil de acertar e de testar.
Há também o risco de ciclos: A emite um evento que faz B emitir outro, que faz A reagir de novo. Ninguém desenhou isso, e ele só aparece em produção.
O critério prático que se consolidou: coreografia para fluxos curtos e simples (2 a 3 passos, sem compensação complexa); orquestração para processos longos, com muitos passos, compensação e necessidade de auditoria. Sistemas maduros usam os dois, em lugares diferentes.
Exemplo prático
Um fluxo de pedido em coreografia:
Pedidos emite PedidoCriado
Pagamento ouve PedidoCriado → cobra → emite PagamentoAprovado | PagamentoRecusado
Estoque ouve PagamentoAprovado → reserva → emite EstoqueReservado | EstoqueIndisponivel
Logística ouve EstoqueReservado → agenda
Pedidos ouve PagamentoRecusado, EstoqueIndisponivel → cancela
Funciona bem e é fácil de estender. A dificuldade aparece na última linha: quando o estoque falha depois de o pagamento ter sido aprovado, alguém precisa estornar — e essa regra vive dentro do serviço de pagamento, reagindo a um evento do estoque.
Com cinco ou seis passos e várias compensações cruzadas, esse emaranhado passa a justificar um orquestrador.
Relacionado
Parte de Messaging · roadmap.sh/system-design