No universo de arquitetura de microserviços, as Sagas surgem como uma alternativa para lidar com transações distribuídas de forma mais simples e resiliente. Quando várias operações precisam ser realizadas em diferentes serviços, surge o desafio de manter a consistência e a confiabilidade do fluxo de negócio. Nesse contexto, Sagas são padrões que nos ajudam a orquestrar transações em múltiplos microserviços, permitindo compensações em caso de falha.

Este artigo inaugura uma série em que exploraremos cada tipo de Saga em detalhes. Aqui, vamos apresentar o conceito geral, por que as Sagas são importantes e quais são as principais abordagens existentes para implementá-las. Nos artigos seguintes, cada tipo de Saga será explorado em profundidade, com exemplos e boas práticas.

1. O Desafio das Transações em Microserviços

Em um sistema monolítico tradicional, uma transação (geralmente via banco de dados) pode garantir atomicidade, consistência, isolamento e durabilidade (ACID) de modo relativamente simples. Já em um ambiente de microserviços:

1. Serviços Independentes
   Cada serviço tem seu próprio banco de dados e regras de negócio específicas.
2. Comunicação Distribuída
   As ações para concluir um processo de negócio podem envolver várias chamadas de API, filas de mensagens ou eventos.
3. Falhas Parciais
   Qualquer serviço ou comunicação pode falhar, levando a estados inconsistentes se não houver um plano de reversão ou compensação.

Garantir a consistência em transações que atravessam vários serviços é desafiador. É aí que entram as Sagas, oferecendo uma maneira de coordenar (ou coreografar) múltiplas etapas de forma que o sistema inteiro possa desfazer os passos caso um deles falhe no meio do processo.

2. O Conceito de Saga

A ideia de Saga vem da computação distribuída e refere-se a uma sequência de transações (ou ações) que podem ser parcialmente revertidas via passos de compensação. Na prática, cada microserviço executa um passo da transação global. Se tudo ocorrer bem, o fluxo termina normalmente. Se algum passo falhar, a Saga inicia as compensações, revertendo os passos anteriores para manter a consistência.

2.1 Estrutura Básica de uma Saga

Podemos representar uma Saga como uma lista de passos:

T1, T2, T3, ..., Tn

Cada passo T possui uma contrapartida de compensação, algo como C1, C2, C3, ..., Cn. Se T3 falha, a Saga executa C2, C1 para voltar a um estado consistente.

3. Principais Tipos de Sagas

Existem duas abordagens principais para implementar Sagas em microserviços:

1. Saga com Coreografia (Choreography-Based Saga)
2. Saga com Orquestração (Orchestration-Based Saga)

Ambas lidam com a ideia de transações distribuídas, mas diferem na forma como coordenam (ou não) as etapas e as compensações.

3.1 Saga com Coreografia

Na Coreografia, cada microserviço decide por conta própria quando executar sua ação e se deve disparar compensações — tudo baseado em eventos. Não há um componente central “mandando” no fluxo. Imagine:

1. Serviço A inicia a transação publicando um evento.
2. Serviço B reage a esse evento e executa sua lógica, depois publica outro evento.
3. Serviço C escuta o evento de B e faz sua parte, publicando mais um evento...
4. Se algo falhar, publica-se um evento de compensação e cada serviço reage individualmente.

Vantagens:

• Baixo acoplamento entre serviços.
• Escalabilidade, pois não há um ponto central de coordenação.

Desafios:

• Fluxo mais difícil de rastrear (muitos eventos espalhados).
• Maior complexidade para compreender todo o processo de negócio, pois a lógica de coordenação está distribuída.

3.2 Saga com Orquestração

Já na Orquestração, um serviço central (às vezes chamado de Orquestrador ou Coordenador) controla a execução dos passos:

1. Orquestrador chama o Serviço A.
2. Ao receber sucesso de A, chama o Serviço B.
3. Ao receber sucesso de B, chama o Serviço C.
4. Se algum passo falhar, dispara as chamadas de compensação nos serviços anteriores.

Vantagens:

• Fluxo de trabalho centralizado e mais fácil de entender.
• Visão clara de cada passo, já que existe um “diretor” comandando a sequência.

Desafios:

• Introduz um componente central que, se falhar, pode comprometer todo o fluxo.
• Pode aumentar o acoplamento em torno do Orquestrador.

4. Exemplos de Uso de Sagas

4.1 Reserva de Viagem

Imagine um cenário com três serviços: Reserva de Voo, Hotel e Pagamento. Em uma Saga, tentamos:

1. Reservar o voo.
2. Reservar o hotel.
3. Confirmar o pagamento.

Se a reserva do hotel falhar no passo 2, é necessário cancelar o voo no passo de compensação. Em coreografia, cada serviço publicaria eventos como “Voo Reservado”, “Falha no Hotel”, para que o serviço de voo saiba que deve desfazer a reserva. Em orquestração, um orquestrador central chamaria cada serviço em sequência e, no erro, executaria chamadas de cancelamento.

4.2 Pedido em E-commerce

Um sistema de e-commerce pode envolver vários microserviços: Carrinho, Pagamento, Inventário e Entrega. A Saga garante que, se o pagamento falhar, as reservas no inventário serão desfeitas ou que, se o inventário estiver indisponível, o pagamento seja estornado.

5. Série de Artigos: O que Vem pela Frente

Neste primeiro artigo, demos uma visão geral das Sagas e seus tipos. Nos próximos artigos, vamos aprofundar cada tipo, abordando pontos como:

1. Saga com Coreografia
   • Como projetar e publicar eventos.
   • Mecanismos para lidar com falhas em cada serviço.
   • Boas práticas de logs e observabilidade.
2. Saga com Orquestração
   • Padrões de implementação de um orquestrador (ex.: BPMN, ferramentas como Camunda, AWS Step Functions, etc.).
   • Como lidar com compensação em um fluxo centralizado.
   • Cuidados com desempenho e tolerância a falhas do orquestrador.
3. Estratégias de Compensação e Resiliência
   • Desenho das “ações de rollback”.
   • Manejo de estados intermediários.
   • Convivência entre diferentes serviços que tenham dados em diferentes estágios de atualização.
4. Casos de Uso e Exemplo Prático
   • Exemplificar em uma aplicação simples, como um e-commerce ou reserva de viagem.
   • Explorar logs e dashboards para visualizar o fluxo da Saga.

6. Conclusão

As Sagas são um pilar essencial para garantir consistência em sistemas distribuídos baseados em microserviços, pois permitem reverter passos sem precisar de transações distribuídas ACID clássicas (que, na prática, são difíceis de implementar em grande escala). Entender a diferença entre coreografia e orquestração é fundamental para escolher o padrão adequado ao seu contexto de negócio e de desenvolvimento.

Fique ligado nos próximos artigos, onde aprofundaremos cada tipo de Saga, com detalhes de implementação, vantagens, desvantagens e dicas de boas práticas. Se você tem exemplos ou dúvidas sobre Sagas em microserviços, deixe seu comentário!

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ências Bibliográficas e Sumário de Termos Principais

Para complementar o artigo sobre Sagas em Microserviços e aprofundar conceitos como ACID, segue abaixo a referências bibliográfica base, o livro Arquitetura de Software: As partes difíceis, que servirá como base — além de um sumário (ou mini-glossário) para os principais termos citados nos estudos de transações distribuídas, microserviços e consistência de dados.

1. Referências Bibliográficas

1. [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.

2. Sumário (Mini-Glossário) dos Principais Termos

2.1 ACID

Atomicidade, Consistência, Isolamento e Durabilidade (ACID) são propriedades que descrevem o comportamento de transações em sistemas de banco de dados:

• Atomicidade (Atomicity): a transação é tratada como uma única unidade. Ou tudo é executado, ou nada.
• Consistência (Consistency): o sistema passa de um estado consistente para outro estado igualmente consistente, respeitando restrições definidas (regras de negócio e de integridade).
• Isolamento (Isolation): mudanças realizadas por uma transação não devem interferir em outras em andamento.
• Durabilidade (Durability): após ser confirmada (commit), a transação permanece gravada de forma permanente, mesmo em caso de falhas.

2.2 Sagas

Sagas são um padrão de transações distribuídas que permite a execução de múltiplas etapas (em diferentes serviços) com possibilidade de compensação. Se uma das etapas falha, etapas anteriores podem ser desfeitas através de ações compensatórias. Exemplos:

• Saga com Coreografia: cada serviço reage a eventos, decidindo se segue ou dispara compensações.
• Saga com Orquestração: um orquestrador central controla a ordem das chamadas e das compensações.

2.3 Transação Distribuída

Refere-se a operações que englobam múltiplos recursos (bancos de dados, serviços) em um fluxo único de negócio. Pela dificuldade de implementar ACID de forma estrita em ambientes distribuídos, surgiram alternativas como Sagas e Consistência Eventual.

2.4 Compensação

Ação de “desfazer” uma etapa previamente executada. Em uma Saga, cada passo T tem uma contraparte compensatória (C) que reverte as mudanças efetuadas, caso seja necessário.

2.5 Microserviços

Arquitetura onde uma aplicação é dividida em pequenos serviços independentes, cada um com seu próprio banco de dados e lógica de negócio. Favorece escalabilidade e resiliência, mas eleva a complexidade de coordenação e comunicação entre serviços.

2.6 Consistência Eventual

Em sistemas distribuídos de larga escala, nem sempre é possível manter consistência imediata. A consistência eventual aceita que diferentes partes do sistema fiquem temporariamente desatualizadas, convergindo para um estado consistente após algum tempo.

2.7 Orquestração x Coreografia

Dois estilos para coordenação de microserviços em Sagas:

• Orquestração: um serviço central (orquestrador) gerencia o fluxo das etapas e das compensações.
• Coreografia: cada serviço reage a eventos e decide seu próximo passo, sem dependência de um coordenador central.

3. Estrutura Sugerida para Estudos Avançados

1. Conceitos Fundamentais de Transações
   • Revisão de ACID em bancos relacionais e como esses princípios se aplicam (ou não) em microserviços.
2. Arquitetura de Microserviços
   • Independência de dados, padrões de comunicação (REST, Mensageria, gRPC) e desafios de governança.
3. Sagas: Motivação e Aplicabilidade
   • O porquê de Sagas substituírem transações distribuídas clássicas (2PC).
4. Padrões de Implementação
   • Comparação aprofundada entre Coreografia e Orquestração.
   • Exemplo passo a passo de um fluxo de pagamento ou reserva de viagem.
5. Compensação e Boas Práticas
   • Design das operações de compensação, logging e rastreabilidade de eventos.
6. Casos de Uso e Ferramentas
   • Orquestradores (Camunda, AWS Step Functions, Temporal.io etc.)
   • Eventos e Mensageria (Kafka, RabbitMQ, NATS).
7. Monitoramento e Observabilidade
   • Logging, tracing distribuído e métricas para identificar gargalos em Sagas.
8. Desafios e Tendências Futuras
   • Arquiteturas reativas, serverless e uso de Sagas em cenários de alta escalabilidade.