Padrões de coreografia versus orquestração

Quando os microsserviços precisam trabalhar juntos para concluir um processo empresarial, há dois padrões fundamentais de coordenação. A Orchestration usa um coordenador central (como Step Functions) que comanda explicitamente cada serviço. A Choreography não tem um coordenador central — os serviços escutam eventos e reagem de forma independente. Entender qual usar e quando combiná-los é uma habilidade arquitetural importante avaliada na prova SAA-C03.

Na orquestração, um serviço central (o orquestrador) controla a sequência de operações. Ele chama o Serviço A, aguarda a resposta, depois chama o Serviço B e assim por diante. O orquestrador tem visibilidade completa do estado do processo, gerencia erros e novas tentativas e pode tomar decisões com base nos resultados intermediários. Na AWS, Step Functions é o orquestrador principal — ele define todo o fluxo de trabalho como uma máquina de estado e conduz cada etapa.

Na coreografia, os serviços se comunicam por meio de eventos sem um coordenador central. O Serviço A conclui sua tarefa e publica um evento (por exemplo, OrderValidated) em um barramento de eventos ou tópico. O Serviço B escuta eventos OrderValidated e processa o pagamento; em seguida, publica PaymentCharged. O Serviço C escuta PaymentCharged e envia o pedido. Cada serviço é autônomo e desacoplado — ele conhece apenas os eventos que consome e produz, não os outros serviços.

Na AWS, Step Functions é a principal ferramenta de orquestração. Para a coreografia, as principais ferramentas são o Amazon EventBridge (para rotear eventos entre serviços com filtragem baseada no conteúdo), o Amazon SNS (para distribuição simples) e o Amazon SQS (para troca de mensagens ponto a ponto entre serviços). Você pode combinar os padrões: use o EventBridge para a coreografia entre domínios e contextos delimitados, e o Step Functions para orquestrar etapas dentro de um único domínio.

A orquestração oferece visibilidade centralizada — o histórico de execução do Step Functions mostra exatamente em que ponto o fluxo de trabalho está, quanto tempo cada etapa levou e o que falhou. A depuração é simples. A coreografia distribui a visibilidade entre vários serviços e barramentos de eventos — rastrear uma única transação empresarial exige correlacionar registros e eventos entre muitos serviços. Por isso, os sistemas de coreografia dependem muito de IDs de correlação e do rastreamento distribuído (AWS X-Ray) para obter visibilidade de ponta a ponta.

A coreografia oferece acoplamento mais fraco — adicionar um novo serviço que escute eventos existentes não exige alterações nos serviços existentes. Por exemplo, adicionar um serviço de análise que escute eventos OrderPlaced não causa impacto no serviço de pedidos nem no serviço de pagamentos. A orquestração introduz acoplamento mais forte entre o orquestrador e todos os serviços que ele chama — adicionar uma nova etapa exige modificar a definição da máquina de estado, embora os serviços individuais permaneçam isolados.

A orquestração torna o tratamento de erros explícito — os blocos Catch do Step Functions definem estados alternativos para cada tipo de erro, e todo o histórico do fluxo de trabalho mostra o contexto da falha. Na coreografia, o tratamento de erros é distribuído — cada serviço deve lidar com suas próprias falhas e, opcionalmente, publicar um evento de falha ao qual outros serviços possam reagir. Implementar sagas (transações compensatórias para desfazer o trabalho quando uma etapa falha) é muito mais complexo na coreografia do que na orquestração.

Prefira a orquestração quando: o processo empresarial tiver uma sequência linear ou ramificada clara, com resultados explícitos de sucesso ou falha; você precisar de visibilidade centralizada do status do processo para operações ou conformidade; o tratamento de erros envolver lógica complexa de compensação; ou o fluxo de trabalho for de longa duração e precisar sobreviver a reinicializações de serviços. Exemplos: atendimento de pedidos, integração de pacientes e processamento de sinistros de seguros — todos são fluxos de trabalho com requisitos claros de início, fim e auditoria.

Prefira a coreografia quando: os serviços pertencerem a equipes diferentes que não devem ser coordenadas de forma rígida; o sistema precisar permitir a extensão por novos serviços sem modificar os existentes; os eventos representarem fatos em vez de comandos (por exemplo, OrderShipped, não ShipOrder); ou você quiser a máxima escalabilidade, já que não há um gargalo central. Exemplos: ingestão de dados analíticos, distribuição de notificações e registro de auditoria — todos são casos em que vários consumidores independentes reagem ao mesmo evento.

A maioria das arquiteturas AWS do mundo real usa ambos os padrões em diferentes níveis de granularidade. Um híbrido comum é usar a coreografia do EventBridge para desacoplar contextos delimitados (por exemplo, o domínio Order emite eventos; os domínios de inventário, Payment e envio respondem de forma independente), enquanto, dentro do domínio Payment, usa-se a orquestração do Step Functions para coordenar as etapas internas do fluxo de pagamento (cobrança, verificação de fraude, autorização e liquidação). Isso proporciona baixo acoplamento entre domínios, com clareza no processo interno.

No exame, procure estes sinais. Palavras-chave de coreografia: "baixo acoplamento", "os serviços reagem a eventos", "as equipes são responsáveis por serviços independentes", "distribuição para vários consumidores", "adicionar um novo serviço sem alterar os existentes". Palavras-chave de orquestração: "coordenar etapas em sequência", "acompanhar o estado do fluxo de trabalho", "lidar com falhas parciais usando compensação", "etapa de aprovação humana", "processo de longa duração com tratamento de erros". Uma questão que descreve um coordenador central direcionando outros serviços sempre representa orquestração.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: a orquestração usa um coordenador central (Step Functions) para fornecer controle explícito e visível do fluxo de trabalho; a coreografia usa eventos (EventBridge) para obter baixo acoplamento e extensibilidade; e a maioria das arquiteturas de produção combina ambos os padrões em diferentes níveis de granularidade. A seguir, exploraremos o formato do exame SAA-C03 e a estratégia baseada no peso de cada domínio.