No contexto dos oito tipos de Sagas (combinando diferentes abordagens de comunicação, consistência e coordenação), vamos abordar a primeira conhecida como Epic Saga, na qual se busca uma forma de consistência atômica em múltiplos serviços, por meio de chamadas síncronas e orquestração centralizada. Neste artigo, apresentamos como essa abordagem se estrutura, suas principais características e um exemplo ilustrativo de implementação.
1. Definição e Fundamentos
A Epic Saga pode ser descrita pelo tripé:
- Comunicação Síncrona
O orquestrador faz chamadas diretas a cada serviço, aguardando uma resposta antes de prosseguir. - Consistência Atômica (ou quase atômica)
Cada etapa busca refletir um modelo de “tudo ou nada”, com confirmações imediatas ou reversões prontamente acionadas. - Coordenação por Orquestração
Um componente central (orquestrador) conhece a ordem das etapas e, em caso de falha, aciona compensações ou desfaz etapas anteriores.
Embora as Sagas normalmente funcionem com o princípio de “confirma e compensa”, na Epic Saga essa dinâmica procura se aproximar de uma experiência de atomicidade, mantendo as etapas sob controle síncrono e revertendo rapidamente em caso de erro.
2. Principais Elementos de Implementação
2.1 Orquestrador Central
- Responsável pelas Chamadas: Recebe o comando inicial para começar a saga, faz a chamada ao primeiro serviço e espera a resposta.
- Sequência de Execução: Ao receber sucesso de um serviço, chama o próximo. Se falhar, dispara a compensação.
- Registro do Estado: Geralmente mantém um log ou status de cada etapa para saber qual passo foi concluído e quais compensações podem ser necessárias.
2.2 Serviços Integrados
- Operações Locais: Cada serviço executa suas operações (transações locais, atualização de dados etc.).
- Confirmação e Compensação: Ao terminar, indica sucesso ou falha ao orquestrador. Em caso de falha de uma etapa posterior, o próprio orquestrador pode solicitar a compensação.
2.3 Comunicação Síncrona
- Chamadas Bloqueantes: O orquestrador envia requisições (REST, gRPC ou outro protocolo) e aguarda a resposta imediata.
- Timeouts: Cada chamada define um período máximo de espera. Em caso de ausência de resposta dentro do limite, pode-se considerar falha e acionar compensações.
3. Fluxo de Execução (Exemplo)
Suponha um processo de criação de uma conta de cliente que envolva três etapas:
- Cadastrar Usuário (Serviço A)
- Processar Pagamento Inicial (Serviço B)
- Habilitar Acesso (Serviço C)
Passo a passo:
- Início: O orquestrador recebe a solicitação “Criar conta completa”.
- Chamada ao Serviço A: O orquestrador invoca o endpoint de criação de usuário, aguardando confirmação.
- Avanço: Se A retornar sucesso, o orquestrador parte para o Serviço B (pagamento).
- Possibilidade de Falha: Se B falhar, o orquestrador envia ao Serviço A o pedido de compensação (por exemplo, desativar ou remover o cadastro).
- Conclusão: Se B retornar sucesso, o orquestrador chama o Serviço C para habilitar o acesso. Ao final, marca a saga como concluída.
Neste cenário, cada operação é efetivada logo após a resposta do serviço, e uma falha em qualquer ponto aciona as compensações previamente definidas, revertendo as etapas anteriores. Dessa forma, busca-se manter o processo em um estado de “tudo ou nada” do início ao fim.
4. Observações sobre Configuração
4.1 Estado Intermediário
Mesmo com a busca de atomicidade, cada serviço efetiva suas mudanças localmente. A reversão, se necessária, ocorre através de chamadas adicionais de compensação. Não há um “commit global único” que envolva todos os serviços de forma simultânea.
4.2 Latência e Tempo de Resposta
Chamadas síncronas em sequência podem introduzir tempos de espera a cada passo, dependendo do desempenho da rede e da capacidade de cada serviço. Isso é um fator a ser considerado no dimensionamento da solução.
4.3 Controle de Failover
O orquestrador é um componente central que precisa tratar situações de indisponibilidade (seja de si mesmo, seja de algum serviço). Mecanismos de alta disponibilidade e registro persistente de estado são formas de contornar eventuais falhas.
5. Exemplo de Implementação Simplificada
sequenceDiagram
autonumber
participant O as Orquestrador
participant S1 as Serviço 1
participant S2 as Serviço 2
participant S3 as Serviço 3
O->>S1: Chamada síncrona (Etapa 1)
S1-->>O: Resposta OK
O->>S2: Chamada síncrona (Etapa 2)
alt Falha em S2?
S2-->>O: Erro
O->>S1: Solicita Compensação
S1-->>O: Compensado
else Sucesso
S2-->>O: OK
O->>S3: Chamada síncrona (Etapa 3)
S3-->>O: OK
end
O-->>O: Saga Concluída
Nesse diagrama, cada etapa é invocada separadamente e o orquestrador aguarda a resposta. Em caso de erro, dispara a compensação para as etapas anteriores.
6. Conclusão
O padrão conhecido como Epic Saga (Síncrona + Atômica + Orquestração) representa uma abordagem em que a busca por atomicidade aparente é alcançada por meio de comunicação síncrona e coordenação centralizada. Nesse modelo:
- As etapas confirmam seus resultados imediatamente, e, se ocorrer alguma falha, procede-se com a compensação de forma rápida.
- A orquestração gerencia todo o fluxo, etapa a etapa.
- A principal finalidade é reduzir ao máximo a exposição do sistema a estados intermediários, aproximando-se de uma experiência de “tudo ou nada”.
Ainda que as Sagas, em geral, se baseiem em “confirma e compensa”, esta variante foca especialmente em manter as operações sob um controle bem definido, seguindo chamadas síncronas entre os serviços envolvidos. Cada ambiente e cada cenário de negócio podem avaliar se essa abordagem se encaixa em suas necessidades de consistência e modo de operação.
Gostou deste artigo?
- Compartilhe com colegas que possam se interessar pelo assunto.
- Acompanhe a série para aprender cada vez mais sobre como projetar fluxos transacionais e seguros em ambientes de microserviços.
Referência Bibliográfica
- [BASE] Arquitetura de Software: As partes difíceis. (Utilizado como referência principal neste estudo.)
- Explora tópicos avançados de arquitetura, incluindo microserviços, transações distribuídas e estratégias de consistência.