Two-Phase Commit vs Saga: Operações Financeiras em Sistemas Distribuídos

O Dilema da Consistência em Microsserviços Financeiros

Quando separamos uma aplicação monolítica em vários microsserviços independentes, cada pedaço do sistema costuma ganhar seu próprio banco de dados. Na prática, isso significa que a transferência de dinheiro entre duas contas bancárias deixa de ser uma simples transação interna de banco de dados e passa a ser uma comunicação entre serviços distintos que rodam em servidores separados. Manter os saldos corretos sem perder dinheiro no meio do caminho torna-se o maior desafio de engenharia da arquitetura.

Em sistemas financeiros tradicionais, confiava-se cegamente nas propriedades conhecidas como ACID, que garantem que um conjunto de operações ocorra por completo ou seja totalmente desfeito. No entanto, quando os dados estão espalhados por redes diferentes, a física impõe barreiras intransponíveis. Latência de rede, quedas repentinas de servidores e falhas de conexão exigem estratégias de coordenação muito mais sofisticadas do que um simples comando de confirmação local.

A engenharia de software moderna precisa lidar com o fato de que a consistência imediata e perfeita tem um custo altíssimo em termos de disponibilidade e desempenho. Para entender como resolver esse problema, precisamos analisar as duas principais ferramentas disponíveis no mercado: o protocolo clássico Two-Phase Commit e o padrão moderno de arquitetura conhecido como Saga. Cada uma dessas abordagens possui filosofias totalmente opostas sobre como lidar com o risco de falhas.

Entendendo o Protocolo Two-Phase Commit (2PC)

O protocolo Two-Phase Commit, frequentemente chamado apenas de 2PC, é um algoritmo clássico de computação distribuída criado para garantir que múltiplos bancos de dados cheguem a um acordo unânime sobre uma transação. O processo funciona em duas etapas distintas: a fase de preparação e a fase de confirmação. Na prática, um coordenador central pergunta a todos os bancos participantes se eles estão prontos para salvar os dados. Se todos responderem positivamente, o coordenador ordena a gravação definitiva.

O grande problema do 2PC reside na rigidez do seu mecanismo de bloqueio. Durante todo o processo de votação e confirmação, os registros afetados nas tabelas de banco de dados ficam travados, impedindo que qualquer outra transação os modifique. Se a rede falhar ou o coordenador cair no meio do caminho, os recursos permanecem bloqueados por tempo indeterminado, gerando gargalos catastróficos que paralisam o sistema inteiro.

Por causa desse comportamento pessimista, o 2PC raramente é recomendado para arquiteturas modernas de microsserviços expostas à alta concorrência. Embora garanta consistência forte e imediata, o preço pago em disponibilidade e escalabilidade costuma ser insustentável para empresas que processam milhares de transações financeiras por segundo. O sistema torna-se tão frágil quanto o seu elo mais fraco e a sua conexão de rede mais lenta.

A Alternativa do Padrão Saga para Fluxos Distribuídos

O padrão Saga adota uma filosofia completamente diferente para resolver o mesmo problema de consistência em sistemas distribuídos. Em vez de travar todos os recursos simultaneamente até que um acordo seja fechado, a Saga divide uma transação global em uma sequência de transações locais independentes. Cada serviço executa sua etapa, atualiza seu próprio banco de dados e emite um evento para disparar o próximo passo do fluxo financeiro.

Se todas as etapas ocorrerem com sucesso, o fluxo termina e a operação financeira é consolidada. No entanto, se um erro acontecer no meio do caminho — por exemplo, a conta de destino não existir após o débito ter sido realizado —, a Saga executa transações de compensação. Na prática, a compensação funciona como um desfazimento lógico, emitindo um crédito para devolver o dinheiro à conta original, garantindo que o saldo global do sistema permaneça correto.

Essa abordagem elimina os bloqueios de longo prazo típicos do 2PC, permitindo que os serviços continuem processando requisições em alta velocidade. A grande complexidade da Saga transfere-se para o código da aplicação, que precisa ser desenhado para lidar com estados intermediários, falhas parciais e a eventualidade de a compensação demorar alguns segundos para ser concluída.

Orquestração versus Coreografia na Implementação de Sagas

Ao implementar o padrão Saga, os engenheiros precisam escolher entre dois modelos fundamentais de controle: a coreografia e a orquestração. Na coreografia, os microsserviços conversam entre si por meio de um barramento de eventos, como o Apache Kafka ou RabbitMQ. Cada serviço escuta eventos de interesse, executa sua lógica e publica um novo evento, funcionando como uma dança sincronizada onde não existe um líder central.

Por outro lado, a orquestração utiliza um componente centralizado — o orquestrador — que conhece todo o fluxo de negócios e comanda explicitamente cada serviço envolvido na transação financeira. O orquestrador envia comandos diretos e aguarda as respostas, controlando o estado da transação e decidindo quando acionar as compensações caso ocorra algum erro inesperado durante o processo.

Para operações financeiras críticas, a orquestração costuma ser a escolha preferida da engenharia sênior. Ter um ponto central de controle facilita muito a auditoria, o rastreamento de erros e a visualização do estado atual de uma transferência complexa, evitando que eventos perdidos ou mensagens duplicadas corrompam o estado financeiro da instituição.

Idempotência: O Segredo para Operações Financeiras Seguras

Independentemente de você escolher o protocolo Two-Phase Commit ou o padrão Saga, existe um conceito técnico indispensável que não pode ser ignorado: a idempotência. Na prática, a idempotência significa que executar a mesma operação financeira várias vezes produz exatamente o mesmo resultado do que executá-la apenas uma vez, sem gerar cobranças duplicadas ou créditos indevidos.

Em redes distribuídas, mensagens de pagamento podem ser entregues mais de uma vez devido a timeouts, instabilidades de conexão ou novas tentativas automáticas de envio. Se um serviço de pagamento não for idempotente, um problema de rede pode fazer com que o cliente seja debitado duas vezes pela mesma compra. Para evitar isso, os sistemas utilizam chaves de idempotência únicas enviadas no cabeçalho das requisições, permitindo que o servidor reconheça e ignore comandos duplicados.

Implementar chaves de idempotência exige armazenamento persistente com restrições de unicidade no banco de dados. Quando uma requisição chega com uma chave já processada, o sistema retorna a resposta anterior armazenada em cache, garantindo total segurança e previsibilidade para o usuário final e para os auditores financeiros da empresa.

Considerações Finais sobre Consistência e Arquitetura

A escolha entre Two-Phase Commit e o padrão Saga resume-se ao eterno trade-off da engenharia de software entre consistência estrita e disponibilidade operacional. Enquanto o 2PC oferece simplicidade teórica ao custo de gargalos severos de desempenho e pontos únicos de falha, o padrão Saga abraça a complexidade assíncrona para garantir alta escalabilidade e resiliência em sistemas modernos.

Para sistemas financeiros que operam em escala global, a aceitação da consistência eventual proporcionada pelas Sagas tornou-se o padrão da indústria. Compreender os riscos, projetar mecanismos sólidos de compensação e garantir a idempotência das operações são os pilares fundamentais para construir arquiteturas distribuídas robustas, confiáveis e capazes de suportar o crescimento contínuo do negócio.