Comparativo dos Principais Padrões de Saga em Microserviços · kusmin

As Sagas são uma solução para manter a consistência de dados em sistemas distribuídos, permitindo que cada serviço confirme (commit) suas alterações localmente e, em caso de falha futura, inicie compensações para reverter as etapas anteriores. Entretanto, existem diferentes formas de implementar esse conceito, variando a comunicação (síncrona vs. assíncrona), o tipo de consistência (atômica vs. eventual) e a coordenação (orquestrada vs. coreografada). Abaixo, reunimos os principais padrões, suas características, vantagens, desvantagens e dicas para lidar com Sagas em geral.

1. Visão Geral dos Padrões

No total, há oito combinações clássicas (2×2×2) resultantes de:

Comunicação:
- Síncrona: O chamador aguarda a resposta imediata do serviço.
- Assíncrona: O chamador dispara uma mensagem/evento e não bloqueia esperando resposta.
Consistência:
- Atômica: Foca em um modelo “tudo ou nada”, aproximando-se de transações ACID distribuídas, com todas as etapas confirmadas simultaneamente (ou revertidas).
- Eventual: Aceita estados intermediários; se ocorrer falha em um passo, as etapas anteriores são compensadas posteriormente, havendo um intervalo de inconsistência.
Coordenação:
- Orquestrada: Um componente central (orquestrador) define a ordem dos passos e aciona compensações.
- Coreografada: Cada serviço decide suas ações de forma independente, reagindo a eventos de sucesso/falha.

Abaixo, listamos cada padrão, seguido de suas vantagens, desvantagens e exemplos de uso.

2. Principais Padrões Saga

2.1 Epic Saga (Síncrona + Atômica + Orquestração)

Comunicação: Síncrona
Consistência: Atômica
Coordenação: Orquestrada

Vantagens

Modelo de transação “quase ACID” (tudo ou nada).
Orquestrador central simplifica visualização do fluxo.

Desvantagens

A escalabilidade tende a ser menor (chamadas síncronas e bloqueantes).
Exige forte acoplamento ao orquestrador.
Risco de timeouts e travamentos.

Uso Típico

Cenários de poucos serviços, fluxo linear e pouca tolerância a estados intermediários.

2.2 Phone Tag Saga (Síncrona + Atômica + Coreografia)

Comunicação: Síncrona
Consistência: Atômica
Coordenação: Coreografada

Vantagens

Dispensa orquestrador, cada serviço chama o próximo na cadeia.
Mantém intenção de atomicidade (falhou em um passo, compensa anteriores rapidamente).

Desvantagens

Complexidade aumenta sem uma visão global.
Cada serviço precisa saber quem chamar em sucesso/falha.
Difícil rastrear fluxos em cenários de grande escala.

Uso Típico

Poucos serviços com alto grau de interdependência e desejo de atomicidade.

2.3 Fairy Tale Saga (Síncrona + Eventual + Orquestração)

Comunicação: Síncrona
Consistência: Eventual
Coordenação: Orquestrada

Vantagens

Uso de um orquestrador simplifica a lógica de compensação.
Chamadas síncronas passo a passo, controle linear.
Aceita estados temporariamente inconsistentes, mas com compensação central.

Desvantagens

Cada passo bloqueia a continuação; se um serviço atrasar, toda a saga espera.
Falha no orquestrador interrompe o processo.
Ainda há “confirma e compensa”, sem atomicidade estrita.

Uso Típico

Fluxos moderados, tolerantes a latências do estilo “chama e espera”, com desejo de monitorar cada etapa centralmente.

2.4 Time Travel Saga (Síncrona + Eventual + Coreografia)

Comunicação: Síncrona
Consistência: Eventual
Coordenação: Coreografada

Vantagens

Não há orquestrador para centralizar a lógica.
Serviços conversam entre si, revertendo passos quando necessário.
Pode funcionar em cenários simples, com poucos serviços.

Desvantagens

Rastreio distribuído de falhas e compensações.
Cada serviço precisa conhecer quem chamar em seguida e como “voltar no tempo” quando algo falha.
Maior dificuldade de manutenção.

Uso Típico

Processos de complexidade baixa, que permitem comunicações ponto a ponto.

2.5 Fantasy Fiction Saga (Assíncrono + Atômica + Orquestração)

Comunicação: Assíncrona
Consistência: Atômica
Coordenação: Orquestrada

Vantagens

“Preparar e confirmar” próximo de um Two-Phase Commit, porém gerenciado por um orquestrador.
Evita bloqueios síncronos, aliviando gargalos de rede.
Maior desacoplamento e escalabilidade.

Desvantagens

Complexidade de troca de mensagens e retentativas (idempotência necessária).
A busca de atomicidade exige lógica semelhante ao 2PC, com fase de “prepare” e “commit”.
Ponto único de coordenação (orquestrador).

Uso Típico

Processos que requerem semelhança com transações distribuídas atômicas e se beneficiam de comunicação não bloqueante.

2.6 Horror Story Saga (Assíncrono + Atômica + Coreografia)

Comunicação: Assíncrona
Consistência: Atômica
Coordenação: Coreografada

Vantagens

Desacoplamento via mensagens.
Tentativa de “tudo ou nada” sem orquestrador, cada serviço coordenando-se por eventos.
Alta escalabilidade teórica, pois não há ponto central.

Desvantagens

Implementar atomicidade sem orquestrador pode se assemelhar a um “horror” pela complexidade de garantir que todos confirmem ou revertam simultaneamente.
Necessário um protocolo robusto de eventos para sincronizar commits/rollbacks.

Uso Típico

Casos bem específicos onde se deseja um 2PC-like distribuído e não se pode ter orquestrador, mas aceita alta complexidade de implementação.

2.7 Parallel Saga (Assíncrono + Eventual + Orquestração)

Comunicação: Assíncrona
Consistência: Eventual
Coordenação: Orquestrada

Vantagens

Orquestrador dispara múltiplos serviços em paralelo, reduzindo latência global.
Boa escalabilidade e desacoplamento, cada serviço trabalha ao seu tempo.
Em caso de falha, orquestrador gerencia compensações.

Desvantagens

Requer registro de estado no orquestrador para acompanhar cada serviço.
Se o orquestrador falhar, o fluxo fica interrompido.
Dificuldade de depuração quando vários serviços falham simultaneamente.

Uso Típico

Quando se quer executar diversas tarefas independentes em paralelo, mas ainda com orquestração central.

2.8 Anthology Saga (Assíncrono + Eventual + Coreografia)

Comunicação: Assíncrona
Consistência: Eventual
Coordenação: Coreografada

Vantagens

Cada serviço reage a eventos, sem um orquestrador único.
Alto desacoplamento, facilitando escalabilidade e evolução de cada parte.
Especialmente útil em grandes ecossistemas de microserviços.

Desvantagens

Difícil entendimento do estado global, pois cada serviço toma decisões sozinho.
Compensações distribuídas exigem sólidos protocolos de evento e idempotência.
Tempo de convergência para consistência pode ser longo.

Uso Típico

Ambientes com muitos microserviços, onde a coordenação central seria inviável; cada parte se integra via mensageria com fluxos reativos.

3. Vantagens e Desafios Gerais das Sagas

3.1 Vantagens

Evita 2PC (Two-Phase Commit) puro: Sagas são mais flexíveis, escaláveis e resilientes a falhas de rede.
Modelo de “Confirma e Compensa”: Permite a cada serviço cometer transações localmente, revertendo apenas quando necessário.
Maior Independência dos Serviços: Cada microserviço controla sua base de dados.

3.2 Desafios

Coerência do Fluxo: Em qualquer padrão, é preciso design cuidadoso de compensações e rastreamento de estados.
Observabilidade: Logs, tracing distribuído e correlação de eventos/requisições são fundamentais.
Idempotência: Tanto serviços quanto compensações devem ser idempotentes, pois mensagens podem ser reenviadas ou chegar em outra ordem.
Gerência de Falhas: Definir timeouts, retentativas e fallback para caso algum serviço fique indisponível.

4. Técnicas para Lidar com Sagas

Idempotência e Identificadores Únicos
- Atribuir um requestId ou transactionId a cada ação, garantindo que replays ou duplicações não causem efeitos irreversíveis.
Registro de Estados/Logs
- Orquestradores (ou cada serviço, no caso de coreografia) mantêm logs do que foi feito, facilitando a persistência do ponto de retomada se ocorrer falha no meio do processo.
Timeout e Retentativas
- Em qualquer padrão (principalmente nos assíncronos), definir quantas vezes retentar se um serviço não responder, e por quanto tempo esperar (para evitar bloqueios).
Circuit Breaker e Bulkhead
- Padrões de resiliência que impedem que a falha de um serviço arraste todo o sistema.
- Útil principalmente quando a comunicação é síncrona ou onde existe um orquestrador central, prevenindo cascata de erros.
Observabilidade
- Ferramentas de log distribuído (ELK, Splunk), métricas (Prometheus, Grafana) e tracing (Jaeger, Zipkin) ajudam a identificar em qual etapa a Saga falhou, quais compensações foram acionadas etc.
Testes de Chaos e Cenários de Falha
- Simular perda de rede, latência alta ou indisponibilidade parcial de serviços, validando se as compensações se comportam corretamente.

5. Conclusão

Cada padrão de Saga equilibra comunicação, consistência e coordenação de forma diferente, oferecendo vantagens em determinados contextos e impondo desafios específicos:

Síncrona vs. Assíncrona: trade-off entre blocos e alta latência (síncrono) versus maior escalabilidade e complexidade de mensageria (assíncrono).
Atômica vs. Eventual: “tudo ou nada” ou “confirma e compensa”? A atomicidade requer mais cuidado ou um pseudo-2PC; a consistência eventual tolera períodos de incoerência.
Orquestrada vs. Coreografada: Um ponto central de controle facilita a compreensão, mas pode se tornar gargalo. A coreografia distribui a inteligência, demandando protocolos de evento mais robustos e dificultando a visibilidade global.

Escolher a abordagem depende da quantidade de serviços envolvidos, do nível de desacoplamento desejado, do grau de tolerância a estados intermediários e do esforço que a equipe de engenharia está disposta a empregar na orquestração ou na mensageria de eventos. Independentemente do padrão, idempotência, monitoramento, técnicas de compensação e testes de resiliência são essenciais para o sucesso das Sagas em ambientes de microserviços.