Em algum momento, todo sistema distribuído precisa responder uma pergunta desconfortável:

quem coordena o processo?

No começo, parece simples.

Um serviço publica OrderCreated.

Outro serviço escuta e reserva estoque.

Outro escuta e inicia pagamento.

Outro escuta e dispara comunicação.

Tudo parece desacoplado. Cada serviço reage ao que importa para ele. O Kafka distribui os eventos, os consumidores trabalham em paralelo e ninguém chama ninguém diretamente.

Até o processo crescer.

Agora o pagamento pode falhar, o estoque pode expirar, a entrega depende de janela logística, o cliente pode cancelar, a antifraude pode pedir revisão manual e cada etapa precisa saber o que fazer quando uma etapa anterior não terminou como esperado.

Nesse ponto, a pergunta volta:

quem sabe onde o processo está?

Se a resposta for "ninguém exatamente", talvez o sistema não esteja coreografado.

Talvez ele esteja apenas espalhado.

O que é coreografia

Coreografia é um estilo em que não existe um coordenador central controlando todo o fluxo.

Cada serviço reage a eventos relevantes e publica novos eventos quando seu trabalho termina.

Um fluxo de pedido poderia funcionar assim:

  • OrderCreated dispara reserva de estoque;
  • o serviço de estoque publica InventoryReserved;
  • o serviço de pagamento reage e publica PaymentAuthorized;
  • o serviço de entrega reage e publica ShipmentScheduled;
  • o serviço de pedidos atualiza sua visão quando recebe os eventos finais.

Nenhum serviço manda nos outros.

Cada participante conhece os eventos que consome, as regras locais que aplica e os eventos que publica como consequência.

Essa abordagem combina bem com Kafka porque o broker entrega fatos para vários consumidores sem exigir chamada direta entre produtor e consumidor.

O ganho é claro: serviços ficam mais autônomos, novos consumidores podem entrar sem mudar o produtor e o fluxo pode evoluir por reação a eventos.

Mas autonomia não elimina coordenação.

Ela só muda onde a coordenação aparece.

O que é orquestração

Orquestração é o estilo em que existe um componente responsável por conduzir o processo.

Esse componente pode ser chamado de orquestrador, process manager, workflow engine, saga coordinator ou serviço de aplicação, dependendo da arquitetura.

O nome importa menos do que a responsabilidade.

Ele sabe quais etapas precisam acontecer, em que ordem, quais resultados espera, quais timeouts existem e quais compensações devem ser executadas em caso de falha.

Num fluxo de pedido, o orquestrador poderia:

  • receber o comando para iniciar o checkout;
  • solicitar reserva de estoque;
  • aguardar confirmação;
  • solicitar autorização de pagamento;
  • aguardar resultado;
  • solicitar agendamento de entrega;
  • concluir o pedido ou iniciar compensações.

Isso pode acontecer com chamadas síncronas, mensagens assíncronas ou uma combinação dos dois.

Kafka pode participar desse desenho como meio de comunicação entre etapas, como log de eventos do processo ou como fonte de fatos que alimentam o orquestrador.

O ponto central é que existe um lugar explícito onde o estado do processo é acompanhado.

A falsa escolha entre acoplado e desacoplado

Muita discussão sobre coreografia e orquestração começa errada porque assume uma oposição simples:

orquestração é acoplada.

coreografia é desacoplada.

Não é tão simples.

Coreografia reduz acoplamento direto, mas pode criar acoplamento indireto.

O serviço de pagamento "só" consome InventoryReserved, mas na prática ele está assumindo que estoque vem antes de pagamento. O serviço de entrega "só" consome PaymentAuthorized, mas na prática ele depende de pagamento já ter validado parte do processo. O serviço de pedidos "só" escuta eventos finais, mas precisa interpretar uma combinação de resultados para saber se o pedido está concluído, pendente ou falhou.

Ninguém chamou ninguém.

Mas a ordem do processo está espalhada nos consumidores.

Esse é o acoplamento invisível da coreografia mal desenhada.

Já a orquestração cria uma dependência mais explícita.

Os participantes passam a responder a solicitações do orquestrador ou publicar resultados esperados por ele. Isso aumenta a centralidade daquele componente, mas também torna o fluxo mais observável e mais fácil de raciocinar quando a regra de processo fica complexa.

O problema não é um modelo ser acoplado e o outro ser livre.

O problema é onde o acoplamento fica e se a equipe consegue enxergá-lo.

Quando a coreografia funciona bem

Coreografia costuma funcionar melhor quando os eventos representam fatos de negócio claros e os consumidores conseguem reagir de forma relativamente independente.

Ela é uma boa opção quando:

  • o produtor não precisa conhecer quem consome;
  • novos consumidores podem surgir sem alterar o fluxo principal;
  • cada reação tem regra local clara;
  • a ordem global do processo é simples;
  • falhas em um consumidor não deveriam bloquear todos os outros;
  • o domínio tolera consistência eventual.

Um exemplo saudável é um evento CustomerRegistered.

Um serviço pode enviar boas-vindas. Outro pode criar uma projeção para atendimento. Outro pode alimentar analytics. Outro pode atualizar uma base antifraude.

Essas reações não precisam formar uma sequência rígida.

Se analytics atrasar, o e-mail não deveria depender disso.

Se a projeção de atendimento falhar, a antifraude não deveria parar.

Nesse cenário, coreografia reduz fricção e permite evolução independente.

O Kafka é muito forte nesse tipo de distribuição de fatos.

Quando a coreografia começa a virar problema

O sinal de alerta aparece quando a coreografia deixa de ser reação independente e vira fluxo de negócio escondido.

Alguns sintomas:

  • para entender o processo, é preciso abrir cinco consumidores diferentes;
  • a ordem real das etapas está implícita nos eventos consumidos;
  • compensações ficam espalhadas e inconsistentes;
  • timeouts são tratados de formas diferentes por cada serviço;
  • não existe uma visão clara de "em que estado este processo está";
  • uma mudança de regra exige alterar vários consumidores ao mesmo tempo;
  • o suporte precisa reconstruir manualmente a história em vários tópicos.

Esse tipo de sistema parece elegante no diagrama inicial.

Mas em produção, ele pode virar investigação distribuída.

O pedido não terminou.

Por quê?

O estoque reservou, mas o pagamento não veio.

O pagamento não veio porque não recebeu evento, porque ignorou por regra, porque falhou e foi para DLT, porque aguardava outro dado, ou porque o evento chegou e foi processado com atraso?

Sem um coordenador ou uma visão explícita do processo, responder isso fica caro.

E o custo aparece justamente nos fluxos importantes.

Quando a orquestração faz mais sentido

Orquestração costuma fazer mais sentido quando existe uma jornada de negócio com etapas obrigatórias, decisões condicionais, compensações e necessidade forte de observabilidade.

Ela ajuda quando:

  • existe uma sequência clara de etapas;
  • o processo tem estado próprio;
  • falhas exigem compensação coordenada;
  • timeouts fazem parte da regra;
  • operadores precisam enxergar o andamento;
  • auditoria do fluxo completo é importante;
  • mudanças de regra devem ficar concentradas em um lugar.

Pense em checkout, abertura de conta, emissão de apólice, onboarding corporativo, contestação financeira ou processamento de sinistro.

Nesses casos, não basta que cada serviço "reaja quando der".

Alguém precisa saber se o processo está aguardando pagamento, se a reserva expirou, se a entrega foi bloqueada, se uma compensação foi disparada ou se a jornada terminou com sucesso.

O orquestrador não precisa concentrar regra interna de todos os serviços.

Ele precisa coordenar a jornada.

Cada serviço continua dono da sua capacidade local.

Mas o processo que atravessa vários serviços ganha uma representação explícita.

O risco do orquestrador virar serviço deus

Orquestração também tem armadilhas.

O erro mais comum é transformar o orquestrador em um serviço que sabe demais.

Ele começa coordenando etapas.

Depois passa a validar regra de estoque, calcular preço, decidir risco, montar dados de entrega, conhecer detalhes de pagamento e manipular estados internos de todo mundo.

Nesse ponto, ele deixou de coordenar.

Ele virou centro de gravidade do domínio.

Isso cria outro tipo de acoplamento: todos dependem dele, tudo muda nele e cada serviço perde autonomia real.

Um orquestrador saudável deveria conhecer o contrato das capacidades, não os detalhes internos de cada capacidade.

Ele pode saber que precisa solicitar uma reserva.

Não deveria precisar saber como o estoque calcula disponibilidade por depósito.

Ele pode saber que precisa solicitar autorização de pagamento.

Não deveria carregar regras internas do gateway ou da política antifraude.

Coordenação não é autorização para concentrar domínio indevidamente.

Kafka muda a conversa, mas não decide por você

Kafka facilita coreografia.

Isso não significa que todo processo em Kafka deva ser coreografado.

O broker distribui eventos, preserva log, permite múltiplos consumidores e ajuda muito a separar produtores de consumidores.

Mas ele não sabe qual é a jornada de negócio.

Ele não sabe se um pedido deveria estar aguardando pagamento ou se a reserva já deveria ter sido compensada.

Ele não sabe se uma sequência incompleta é normal, atraso ou incidente.

Essa responsabilidade precisa aparecer em algum lugar da arquitetura.

Pode aparecer distribuída nos consumidores, quando a coreografia é simples e bem desenhada.

Pode aparecer em um orquestrador, quando o processo exige estado explícito.

Pode aparecer em uma combinação dos dois.

O erro é achar que publicar eventos automaticamente resolve coordenação.

Kafka entrega fatos.

Quem desenha o processo é a aplicação.

Um desenho híbrido costuma ser mais realista

Na prática, muitos sistemas maduros usam os dois estilos.

Um orquestrador coordena o fluxo principal de checkout.

Eventos publicados ao longo do processo alimentam projeções, analytics, comunicação, auditoria e antifraude.

O caminho crítico é orquestrado.

As reações laterais são coreografadas.

Isso evita dois extremos ruins.

De um lado, evita espalhar o fluxo principal em dezenas de consumidores que ninguém consegue acompanhar.

Do outro, evita colocar toda reação secundária dentro de um orquestrador central que vira gargalo de evolução.

A fronteira costuma ser esta:

se a etapa define o avanço do processo, ela provavelmente precisa de coordenação explícita.

Se a etapa apenas reage a um fato já consolidado, ela pode ser coreografada.

Essa divisão não é perfeita, mas ajuda muito.

Perguntas para escolher melhor

Antes de decidir entre coreografia e orquestração, vale responder:

  • existe uma sequência obrigatória de etapas?
  • alguém precisa saber o estado atual do processo inteiro?
  • falhas exigem compensação coordenada?
  • timeouts fazem parte da regra de negócio?
  • uma mudança no fluxo exige mexer em muitos consumidores?
  • o suporte consegue explicar onde o processo parou?
  • novos consumidores deveriam entrar sem impactar o caminho principal?
  • o evento representa um fato independente ou uma etapa de workflow?

Essas perguntas tornam a escolha menos ideológica.

Coreografia e orquestração não são estilos concorrentes em abstrato.

São formas diferentes de colocar coordenação no sistema.

O ponto que vale fixar

Todo processo distribuído tem coordenação.

A diferença é se ela está explícita ou espalhada.

Coreografia funciona bem quando serviços reagem a fatos de negócio com autonomia real.

Orquestração funciona melhor quando existe uma jornada com estado, sequência, timeout, compensação e necessidade de visibilidade.

Kafka não elimina essa decisão.

Ele só torna mais fácil distribuir eventos.

Se ninguém consegue responder quem coordena o processo, talvez a arquitetura não esteja desacoplada.

Talvez ela só tenha escondido a coordenação dentro dos consumidores.