Orquestração vs Coreografia: O Argumento da Observabilidade
Coreografia é elegante num quadro branco. Orquestração ganha quando você precisa responder "o que aconteceu de verdade?" às 2 da manhã. O verdadeiro motivo pelo qual o Sagaweaw escolheu orquestração não é controle de fluxo — é observabilidade. Você não consegue reproduzir o que não consegue observar.
O que Coreografia Significa na Prática
Em uma arquitetura baseada em coreografia, não existe um coordenador central. Cada serviço escuta eventos e reage de forma independente. O serviço de pedidos publica OrderCreated. O serviço de estoque captura o evento, reserva o produto e publica StockReserved. O serviço de pagamento captura esse evento, cobra o cartão e publica PaymentCharged. E assim por diante.
Parece lindo num diagrama de sequência. Cada serviço é desacoplado. Ninguém depende diretamente de ninguém. O sistema dá a impressão de que respira sozinho.
O problema é o que acontece quando ele para de respirar.
Falhas Invisíveis
Quando três serviços reagem ao mesmo evento e um falha silenciosamente, quem sabe? Quem faz o retry? Onde está o estado?
Considere este cenário de falha: OrderCreated é publicado. O serviço de estoque processa com sucesso. O serviço de pagamento trava no meio da execução — a cobrança foi tentada, mas nenhum evento PaymentCharged foi publicado. O serviço de envio nunca soube de nada. O cliente vê um pedido confirmado. Seu estoque tem o produto reservado. Nenhum dinheiro foi cobrado.
Para diagnosticar isso em um sistema de coreografia, você precisa:
- Consultar os logs do serviço de estoque pelo ID do pedido
- Consultar os logs do serviço de pagamento pelo mesmo ID
- Consultar a dead-letter queue do broker
- Reconstruir manualmente uma linha do tempo a partir de timestamps de 3+ sistemas com relógios potencialmente defasados
Esse não é um caso de borda contrived. Esse é o seu plantão de terça-feira.
O Problema do "Trace Distribuído como Mentira"
OpenTelemetry e rastreamento distribuído são poderosos. Mas eles mostram spans, não intenções.
Um trace vai te dizer que POST /inventory foi chamado, que levou 47ms e retornou 200. Ele não vai te dizer:
- A qual saga essa chamada pertencia
- Qual era o próximo passo esperado
- Se o resultado foi correto para o fluxo de negócio
- O que deveria acontecer se esse passo precisasse ser compensado
Você consegue ver a maquinaria. Não consegue ver o plano. Quando algo dá errado, você está reconstruindo a intenção a partir de artefatos de execução — como ler um boletim de ocorrência de acidente para entender para onde o motorista pretendia ir.
O Trade-off da Orquestração
Orquestração introduz um coordenador: um serviço (ou biblioteca) que conhece o plano completo. Cada passo é explícito. Cada transição é registrada. A máquina de estados vive em um único lugar.
Isso gera mais acoplamento no nível do coordenador. Esse é o custo honesto. Se o orquestrador tem um bug, ele afeta todos os fluxos. Se ele está indisponível, os fluxos não avançam.
Mas o que você ganha em troca é uma fonte única de verdade para o estado. A qualquer momento, você pode perguntar: "Qual é o estado atual do pedido #12345?" e obter uma resposta definitiva — não uma reconstrução a partir de logs de eventos.
Por que o Dashboard do Sagaweaw Existe
O dashboard do Sagaweaw só é possível por causa da orquestração.
Quando uma saga é executada, cada transição de passo é persistida: qual step executou, qual foi seu resultado, quando começou, quando terminou, se foi compensado. O dashboard lê esses dados e renderiza uma linha do tempo.
Com coreografia, você teria que reconstruir essa linha do tempo a partir de 5 logs de serviços diferentes, correlacioná-los por ID de pedido, lidar com defasagem de relógio e torcer para que nada tenha sido descartado silenciosamente. Isso não é um dashboard — é arqueologia.
Com orquestração, a pergunta "o que aconteceu com essa saga?" tem uma query direta ao banco de dados como resposta.
Quando Coreografia é a Escolha Certa
Coreografia não é errada. Ela é errada para esse problema.
Ela brilha quando:
- Você tem serviços verdadeiramente independentes sem fluxo de negócio compartilhado
- O throughput é extremamente alto e um coordenador central seria um gargalo
- Os eventos representam fatos sobre o mundo, não passos em uma transação que pode falhar
- Não há requisito de compensação — as coisas não precisam ser desfeitas
Streaming de eventos de alto throughput, pipelines de analytics, logs de auditoria — esses são casos naturais para coreografia. Mas para fluxos de negócio com lógica de compensação (pedidos, pagamentos, onboarding), a necessidade de responder "o que aconteceu?" torna a orquestração o padrão correto.
Você não consegue reproduzir o que não consegue observar. E você não consegue observar o que não tem estado central.
Junte-se ao debate!
Arquitetura é feita de trade-offs. O que você achou das decisões tomadas em "Orquestração vs Coreografia: O Argumento da Observabilidade"? Compartilhe seus cenários, tire dúvidas e debata com outros engenheiros da comunidade Sagaweaw.
Comentar no GitHub Discussions