Em uma arquitetura monolítica, manter a consistência transacional é relativamente simples, pois toda a operação ocorre sobre um único banco de dados. Caso qualquer etapa da transação falhe, o SGBD executa automaticamente um rollback, preservando as propriedades ACID (Atomicity, Consistency, Isolation e Durability).
Em uma arquitetura baseada em microsserviços, esse cenário muda completamente. Cada serviço possui autonomia sobre seu próprio banco de dados (Database per Service), eliminando a possibilidade de uma transação distribuída tradicional entre múltiplos domínios. Como consequência, uma operação de negócio passa a ser composta por diversas transações locais independentes.
Considere um fluxo de checkout em um e-commerce: o serviço de Estoque reserva um produto, o serviço de Pagamentos processa a cobrança e o serviço de Pedidos registra a compra. Se o estoque confirmar a reserva, mas o pagamento falhar posteriormente, o banco de dados do serviço de Estoque não possui conhecimento das demais operações para executar um rollback global.
Esse desafio tornou-se um dos principais problemas de consistência em sistemas distribuídos.
A Abordagem Tradicional: Two-Phase Commit (2PC)
Historicamente, a solução para esse problema foi o protocolo Two-Phase Commit (2PC), um mecanismo de coordenação distribuída que garante consistência forte entre múltiplos bancos de dados.
O protocolo opera em duas fases:
- Prepare Phase: um coordenador central solicita que todos os participantes validem se estão aptos a confirmar a transação, mantendo seus recursos bloqueados (locks).
- Commit Phase: caso todos respondam positivamente, o coordenador envia a instrução definitiva de Commit. Caso qualquer participante falhe, é enviado um Rollback para todos.
Essa abordagem fornece consistência imediata, porém apresenta limitações significativas em ambientes distribuídos.
Limitações do 2PC
- Necessidade de bloqueios (locks) durante toda a transação;
- Elevada latência devido à comunicação síncrona entre todos os participantes;
- Baixa escalabilidade em ambientes distribuídos;
- Forte acoplamento entre serviços;
- Existência de um Single Point of Failure (SPOF) representado pelo Coordenador;
- Pouca aderência a ambientes Cloud Native e arquiteturas orientadas a eventos.
Embora ainda seja utilizado em alguns sistemas legados e cenários específicos do setor financeiro, o 2PC tornou-se pouco adequado para arquiteturas modernas de microsserviços.
A Abordagem Moderna: Saga Pattern
O Saga Pattern substitui a consistência imediata por Consistência Eventual (Eventual Consistency), um dos princípios fundamentais de sistemas distribuídos.
Ao invés de executar uma única transação global, uma Saga divide uma operação de negócio em uma sequência de transações locais independentes.
Cada microsserviço:
- executa sua própria transação;
- persiste seus dados localmente;
- publica um evento em um broker de mensagens (como Kafka ou RabbitMQ);
- desencadeia a próxima etapa do fluxo.
Essa abordagem elimina bloqueios distribuídos e aumenta significativamente a disponibilidade e escalabilidade da aplicação.
Transações Compensatórias
Como não existe rollback distribuído, a recuperação de falhas ocorre por meio de Transações Compensatórias (Compensating Transactions).
Caso uma etapa falhe — por exemplo, uma autorização de pagamento recusada — a Saga dispara eventos responsáveis por compensar as operações anteriores.
Exemplo:
- Estoque → Reserva produto
- Pagamento → Falha
- Evento de compensação → Estoque libera novamente a quantidade reservada
Observe que não ocorre um rollback físico da transação anterior; uma nova transação de negócio é executada para restaurar o estado esperado do sistema.
Estratégias de Implementação de uma Saga
Existem duas abordagens predominantes para implementação do padrão Saga.
Coreografia (Choreography)
Na Coreografia não existe um componente central de coordenação.
Cada microsserviço reage aos eventos publicados pelos demais e, quando conclui sua responsabilidade, publica um novo evento para dar continuidade ao fluxo.
Vantagens
- Baixo acoplamento entre serviços;
- Arquitetura altamente distribuída;
- Excelente escalabilidade.
Desvantagens
- Fluxos de negócio tornam-se implícitos;
- Maior dificuldade de observabilidade e rastreamento;
- Complexidade crescente conforme aumenta o número de serviços e eventos.
Orquestração (Orchestration)
Na Orquestração existe um componente dedicado denominado Saga Orchestrator, responsável por controlar explicitamente todo o fluxo da transação distribuída.
Em vez de reagirem a eventos espontaneamente, os serviços recebem comandos do Orquestrador, executam suas operações e retornam o resultado da execução.
Em caso de falha, o Orquestrador dispara automaticamente as transações compensatórias necessárias.
Vantagens
- Fluxo centralizado e explícito;
- Melhor observabilidade;
- Facilidade de auditoria;
- Simplicidade para implementar compensações complexas;
- Modelo amplamente adotado em fluxos críticos de negócio.
Desvantagens
- Introduz um componente adicional na arquitetura;
- O Orquestrador torna-se responsável pela coordenação da lógica de negócio.
Quando Utilizar Cada Abordagem?
Utilize Two-Phase Commit (2PC) quando:
- a consistência forte e imediata for obrigatória;
- houver necessidade de atomicidade absoluta entre múltiplos recursos;
- a latência adicional for aceitável;
- estiver trabalhando em sistemas legados ou ambientes altamente controlados.
Utilize Saga Pattern quando:
- a arquitetura for baseada em microsserviços;
- o sistema precisar escalar horizontalmente;
- houver comunicação assíncrona via eventos;
- o domínio de negócio aceitar Consistência Eventual;
- a prioridade for disponibilidade, resiliência e desacoplamento entre serviços.
Na prática, o Saga Pattern tornou-se o padrão predominante para coordenação de transações distribuídas em aplicações Cloud Native, sendo amplamente utilizado em plataformas de e-commerce, marketplaces, fintechs e sistemas de alta escala executados sobre Kubernetes.
