Coreografia vs Orquestração

Duas formas de coordenar um fluxo entre serviços. Na coreografia cada serviço reage ao evento anterior e publica o próximo; ninguém conhece o fluxo inteiro. Na orquestração um orquestrador chama cada serviço em ordem e guarda o estado de cada execução. O projeto roda o mesmo PIX, com as mesmas regras, pelos dois caminhos para mostrar onde eles diferem.

passos: 6
arquivos: 3
testes: 0
tecnologias: 5

Infraestrutura realTypeScriptBunElysiaRabbitMQDocker

Cenário Relações Comparar

Baixar cartão

Cenário

Um PIX passa por validação de limite (R$ 5.000,00), antifraude (chave denunciada), liquidação e notificação. Os mesmos quatro serviços atendem aos dois caminhos: consomem eventos do RabbitMQ na coreografia e respondem HTTP na orquestração. No fim, o serviço de liquidação sai do ar para mostrar a diferença de comportamento.

Planta

Fluxo

11/11

11 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

6 passos

Eventos livres ou maestro central.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

ack+12

01
As regras ficam em service_pix.ts, iguais para os dois caminhos — o que muda é quem dispara cada etapa
02
CoreografiaCada serviço tem a própria fila durável ligada ao evento que o acorda; publica o próximo evento com confirmação antes do ack
03
Na coreografia a ordem mora nos bindings; saber "onde este PIX parou" exige um observador de todos os eventos (pix.#), e um consumidor novo (auditoria) é só mais uma fila
04
OrquestraçãoO orquestrador chama as etapas em sequência, com timeout, e registra etapa a etapa onde cada PIX parou e por quê
05
Serviço fora do arA orquestração falha na hora, sabendo exatamente em que etapa; na coreografia o evento espera na fila e o fluxo continua quando o serviço volta
06
Os dois caminhos dão o mesmo resultado na fronteira do limite: exatamente R$ 5.000,00 passa, um centavo a mais para na validação

Trade-offs

O que se ganha, o que se paga

Aspecto	Coreografia	Orquestração
Onde está o fluxo	Espalhado nos bindings	Num lugar só, legível
Estado de cada execução	Precisa de observador de eventos	O orquestrador sabe
Serviço fora do ar	Evento espera e o fluxo retoma	Falha imediata na etapa
Novo interessado	Uma fila a mais, sem tocar em ninguém	Mudança no orquestrador
Acoplamento	Serviços só conhecem eventos	Orquestrador conhece todos

apps/service-design/choreography-vs-orchestration

3 arquivos

src/

service_pix.tsRegras dos quatro serviços, comuns aos dois caminhos
choreography_pix.tsConsumidores, publicação confirmada e o observador de eventos
orchestration_pix.tsServiços em HTTP e o orquestrador com o estado de cada PIX

Executar · com Docker

$ ./docker.sh up# sobe RabbitMQ
$ cp .env.example .env# variáveis de ambiente
$ bun install# dependências
$ bun run demo# roda o cenário
$ bun run test# integração contra o serviço real
$

Requisitos: BunDocker
Sobe junto: RabbitMQ

Relações

Onde ele se encaixa

Mapa

Choreography vs Orchestration

Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Choreography vs Orchestration?

Próximo projeto · Padrões de Design de ServiçoCommand

Contatos

Coreografia vs Orquestração