Transações distribuídas: quando usar Saga ou 2PC?

O desafio da consistência em sistemas distribuídos

Quando separamos um sistema monolítico em vários microsserviços, cada componente passa a ter seu próprio banco de dados isolado. Na prática, isso significa que uma operação simples, como fechar um pedido de e-commerce, agora exige salvar dados em serviços diferentes: o de estoque, o de pagamento e o de faturamento. Se o serviço de pagamento falhar após o estoque ser baixado, o sistema precisa reverter o processo. Manter a integridade dos dados sem travar o ecossistema inteiro é o grande dilema da engenharia moderna, forçando equipes a escolherem entre o rigor do bloqueio total e a flexibilidade da consistência eventual, conforme abordamos ao desacoplar bases de dados em microsserviços legados.

Como funciona o commit de duas fases na prática

O commit de duas fases, conhecido como 2PC, é um protocolo clássico que tenta garantir que uma transação em múltiplos bancos ocorra de forma atômica, ou seja, ou tudo é salvo ou nada é alterado. Na primeira fase, chamada de preparação, um coordenador pergunta a todos os bancos participantes se eles conseguem salvar os dados. Cada banco reserva seus registros e responde com um voto positivo ou negativo. Na segunda fase, se todos votaram 'sim', o coordenador envia a ordem de gravação definitiva; se alguém falhar, todos desfazem a operação. Na prática, isso lembra um grupo de amigos onde o passeio só é confirmado se absolutamente todo mundo estiver de acordo.

Os gargalos invisíveis e os riscos operacionais do 2PC

Apesar da rigidez na garantia de consistência, o 2PC possui um calcanhar de Aquiles intransponível em sistemas de alta volumetria: o bloqueio de recursos. Enquanto os bancos aguardam a resposta do coordenador na primeira fase, as linhas afetadas nas tabelas ficam trancadas para outras requisições. Se a rede oscilar ou um dos nós demorar para responder, conexões se acumulam e o banco de dados inteiro sofre uma queda drástica de performance. Em ambientes modernos de nuvem, onde falhas de rede transitórias são comuns, depender de bloqueios síncronos transforma o 2PC em um gerador de gargalos, um problema recorrente que equipes tentam mitigar quando analisam a lentidão com rastreamento distribuído.

A alternativa do padrão Saga e a consistência eventual

Para fugir das armadilhas do bloqueio de recursos, a arquitetura moderna abraçou o padrão Saga. Em vez de uma transação única e travada, a Saga divide o fluxo em uma sequência de transações locais independentes executadas em cada microsserviço. Cada etapa atualiza seu próprio banco e emite um evento informando que o trabalho foi concluído. Na prática, isso funciona como uma linha de montagem industrial: cada estação faz sua parte e repassa o produto para a frente. Se algo der errado na terceira etapa, o sistema não desfaz a transação travando o banco, mas executa ações compensatórias específicas para anular o efeito das etapas anteriores, aceitando que o sistema atinja o estado correto de forma eventual.

Para coordenar essa sequência de passos sem perder o controle do fluxo, os engenheiros costumam escolher entre duas abordagens principais: a coreografia e a orquestração. Na coreografia, os microsserviços conversam entre si por meio de barramentos de mensagens de forma descentralizada, o que funciona bem em fluxos curtos mas pode gerar dependências difíceis de rastrear conforme o sistema cresce. Na orquestração, existe um componente centralizado — o orquestrador — que conhece todo o fluxo de negócios, decide qual serviço chamar em seguida e dispara transações compensatórias automaticamente caso ocorra algum erro inesperado.

Comparando custo, resiliência e complexidade operacional

Escolher entre Saga e 2PC não é uma questão de certo ou errado, mas de aceitar os trade-offs inerentes ao seu modelo de negócio. O 2PC garante consistência imediata sem exigir código complexo de reversão, mas sacrifica a disponibilidade e a escalabilidade sob alta carga. Por outro lado, a Saga exige esforço significativo de desenvolvimento para desenhar transações compensatórias seguras e lidar com estados intermediários inconsistentes, mas garante alta resiliência e tolerância a falhas de rede. Se o seu sistema lida com transações financeiras estritas onde centavos não podem divergir nem por um segundo, o 2PC ou bancos com suporte a transações distribuidas ACID rigidas podem ser necessários; para quase todo o resto da web moderna, a Saga entrega a elasticidade necessária para o crescimento sustentável. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre Por que a IA alucina e como criar barreiras em LLMs.

Considerações finais sobre consistência distribuída

O design de sistemas distribuídos exige abandonar a ilusão de que a rede é totalmente confiável e que os bancos operam sem latência. Compreender as limitações do 2PC e abraçar a complexidade controlada do padrão Saga é um rito de passagem para arquitetos de software que lidam com milhões de requisições diárias. Avalie sempre o impacto de negócio de uma inconsistência temporária antes de optar por travar sua infraestrutura inteira em busca de uma perfeição síncrona inalcançável.