Processamento de Transações Distribuídas com Two-Phase Commit e Padrões Saga em Microsserviços

O Desafio da Consistência de Dados em Arquiteturas de Microsserviços

Quando separamos um sistema monolítico em vários microsserviços independentes, cada serviço costuma possuir seu próprio banco de dados isolado. Na prática, isso significa que uma operação simples do dia a dia, como finalizar uma compra online que atualiza o estoque, cobra o cartão de crédito e gera uma nota fiscal, deixa de acontecer em um único banco centralizado. Em vez disso, essa operação agora exige conversas complexas entre servidores diferentes que podem falhar a qualquer momento por quedas de rede ou lentidão. Garantir que todas essas etapas terminem com sucesso ou que nenhuma delas deixe dados incorretos para trás é o grande quebra-cabeça da consistência de dados distribuídos.

Em sistemas tradicionais, utilizávamos o conceito de ACID, que garante que um conjunto de alterações ocorra de forma atômica ou seja totalmente desfeito se algo der errado. No entanto, em um ambiente distribuído, manter o ACID tradicional em escala global é extremamente custoso e muitas vezes impossível devido à necessidade de alta disponibilidade e tolerância a falhas. É aqui que os engenheiros precisam escolher entre diferentes estratégias de sincronização, ponderando cuidadosamente o custo operacional, a complexidade de desenvolvimento e o impacto direto na experiência do usuário final quando ocorrem falhas parciais.

Como Funciona o Two-Phase Commit na Prática

O algoritmo Two-Phase Commit, frequentemente abreviado como 2PC, é uma abordagem clássica para tentar impor consistência rígida entre múltiplos bancos de dados. Como o próprio nome sugere, o processo ocorre em duas etapas distintas: a fase de preparação e a fase de confirmação. Na primeira fase, um coordenador central pergunta a todos os bancos participantes se eles estão prontos para salvar as alterações. Cada banco verifica seus próprios recursos, garante que não há conflitos e responde com um voto positivo ou negativo. Se todos votarem sim, o coordenador passa para a segunda fase, ordenando que todos efetivem as mudanças permanentemente.

A grande vantagem do Two-Phase Commit é a garantia matemática de que todos os nós participantes chegam exatamente ao mesmo resultado, evitando dados corrompidos ou estados intermediários indesejados. Contudo, na prática cotidiana de grandes sistemas corporativos, o 2PC possui um calcanhar de Aquiles severo conhecido como bloqueio síncrono. Durante todo o processo, os registros nos bancos de dados ficam travados aguardando a resposta do coordenador. Se a rede falhar ou o coordenador cair no meio do caminho, os dados permanecem inacessíveis, derrubando drasticamente a disponibilidade do sistema e gerando gargalhar severos de desempenho.

O Padrão Saga como Alternativa ao Bloqueio Rígido

Como o travamento do Two-Phase Commit se torna inviável em microsserviços de alta escala, a indústria adotou amplamente o padrão Saga. Uma Saga é uma sequência de transações locais executadas de forma independente por cada microsserviço envolvido em uma operação de negócio. Cada serviço atualiza seu próprio banco de dados local imediatamente e publica um evento para o próximo passo da cadeia. Na prática, isso significa que abandonamos a consistência imediata em troca da chamada consistência eventual, onde o sistema aceita que os dados podem estar temporariamente desalinhados por alguns milissegundos até que todas as etapas terminem.

O grande diferencial do padrão Saga reside na gestão de falhas através de ações compensatórias. Se a primeira e a segunda etapas de uma compra ocorrerem com sucesso, mas a terceira etapa falhar por falta de saldo, o sistema não pode simplesmente desfazer o passado de forma mágica. Em vez disso, a Saga executa transações inversas para anular o efeito das etapas anteriores. Por exemplo, se o estoque foi reservado e o pagamento falhou, a Saga dispara uma operação compensatória para devolver o item ao estoque. Esse mecanismo exige que os desenvolvedores desenhem as operações de negócios pensando em como revertê-las de maneira segura e idempotente.

Orquestração versus Coreografia em Sagas Distribuídas

Ao implementar o padrão Saga, arquitetos de software precisam decidir como o fluxo de trabalho será coordenado entre os serviços. A primeira abordagem é a coreografia, onde não existe um ponto central de controle. Cada microsserviço escuta eventos disparados por outros serviços e decide autonomamente qual ação tomar em seguida. É como uma dança improvisada em grupo, onde cada dançarino reage aos movimentos dos colegas ao redor. Embora seja altamente flexível e reduza o acoplamento direto, a coreografia pode se tornar extremamente difícil de depurar e compreender à medida que o sistema cresce e o número de eventos se multiplica.

A segunda abordagem é a orquestração, que introduz um componente centralizador chamado orquestrador de Sagas. Esse componente atua como um maestro de uma orquestra sinfônica, mantendo o controle explícito sobre o estado atual da transação e ditando exatamente qual serviço deve executar a próxima chamada ou qual compensação disparar em caso de erro. Na prática, a orquestração facilita enormemente a visualização do fluxo de negócios e a implementação de políticas de novas tentativas automáticas. No entanto, ela introduz um ponto central de dependência que precisa ser projetado com alta disponibilidade para não derrubar o ecossistema inteiro caso venha a falhar.

Considerações Finais sobre Consistência em Microsserviços

A escolha entre o Two-Phase Commit e o padrão Saga resume um dos maiores dilemas da engenharia de software moderna: o equilíbrio delicado entre consistência forte e disponibilidade operacional. Enquanto o 2PC atende a cenários estritos onde o erro é inaceitável e a infraestrutura é altamente confiável, as Sagas oferecem a resiliência e a escalabilidade necessárias para sistemas modernos na nuvem. Compreender os trade-offs dessas arquiteturas permite que equipes de engenharia tomem decisões pragmáticas, garantindo que o software continue funcionando de maneira previsível mesmo quando partes dele inevitavelmente falham.