Como usar o padrão Saga para garantir consistência em microsserviços

O desafio das transações distribuídas no mundo real

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 perder a capacidade de usar uma única transação de banco para alterar dados em dois lugares ao mesmo tempo resolve problemas de escala, mas cria um dilema arquitetural complexo. Em uma aplicação financeira, por exemplo, debitar o saldo em um serviço de contas e creditar o valor em um serviço de carteiras exige que ambas as ações ocorram com sucesso. Se o segundo serviço falhar após o débito, o sistema fica em um estado inconsistente que corrompe a integridade dos dados.

Historicamente, bancos de dados usavam o protocolo de confirmação em duas etapas, conhecido como Two-Phase Commit ou 2PC, para travar registros em múltiplos nós até que todos confirmassem a alteração. No entanto, esse bloqueio síncrono destrói a performance e a resiliência de arquiteturas modernas na nuvem, pois qualquer queda de rede paralisa a operação inteira. É exatamente para contornar esse gargalo que engenheiros adotam o processamento de transações distribuídas com Two-Phase Commit assíncrono e compensação dinâmica, aceitando que a sincronia imediata deve ceder espaço para modelos mais flexíveis baseados em eventos.

O que é o padrão Saga e como ele funciona na prática

O padrão Saga é uma sequência de transações locais onde cada microsserviço atualiza seu próprio banco de dados e publica um evento ou mensagem para disparar o próximo passo. Na prática, uma Saga transforma uma grande operação de negócio em pequenas etapas independentes que cooperam entre si. Se todas as etapas terminarem sem erros, a operação é considerada concluída com sucesso. No entanto, se o terceiro serviço recusar a requisição por falta de estoque ou instabilidade temporária, o sistema não pode simplesmente travar; ele precisa executar ações corretivas para desfazer o que já foi feito.

Para entender melhor a dinâmica de entrega de mensagens entre esses serviços autônomos, vale notar que como garantir entrega exatamente uma vez em microsserviços torna-se um pilar fundamental de confiabilidade. Sem uma infraestrutura de mensageria robusta que evite duplicidades ou perdas de pacotes, a execução de uma Saga pode gerar estados fantasmas, duplicando cobranças ou perdendo confirmações cruciais durante picos de tráfego na rede.

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

Existem duas abordagens principais para implementar o fluxo de uma Saga: a coreografia e a orquestração. Na coreografia, não existe um controlador central; cada microsserviço escuta eventos baralhados em um canal de mensageria, executa sua lógica e publica um novo evento informando o resultado. Essa abordagem reduz o acoplamento estrutural, mas pode dificultar a visualização do fluxo completo à medida que o sistema cresce e ganha dezenas de novos eventos interconectados.

Por outro lado, a orquestração utiliza um componente dedicado, chamado de orquestrador, que conhece todas as etapas do processo e envia comandos diretos para cada microsserviço envolvido. O orquestrador aguarda a resposta de cada chamada, decide o próximo passo com base no sucesso ou falha e mantém o estado global da transação visível em um único lugar. Embora adicione um ponto central de dependência, simplifica enormemente o tratamento de exceções e a auditoria de processos de negócio complexos e longos.

Transações compensatórias e o princípio da consistência eventual

Como o isolamento rígido entre bancos de dados impede o bloqueio atômico, a consistência eventual assume o papel principal na arquitetura. Isso significa que os dados não estarão idênticos em todos os lugares no exato milissegundo da requisição, mas convergirão para o estado correto após um breve intervalo de tempo. Quando uma falha ocorre na metade do processo, entra em cena a transação compensatória, que funciona como um comando de desfazer lógico para cada operação já efetivada.

Se um pedido de e-commerce reservar o estoque com sucesso, mas o gateway de pagamento recusar o cartão de crédito logo em seguida, a Saga aciona uma transação compensatória no serviço de estoque para devolver os itens reservados às prateleiras virtuais. É importante ressaltar que a compensação não é um comando de banco de dados nativo do tipo rollback, mas sim uma nova operação de negócio que neutraliza os efeitos colaterais da ação anterior, exigindo planejamento cuidadoso para lidar com efeitos colaterais irreversíveis, como o envio de um e-mail de confirmação.

Tratando falhas de concorrência e garantindo idempotência

Sistemas descentralizados que operam com consistência eventual estão inevitavelmente sujeitos a reentregas de mensagens e condições de corrida, onde duas requisições chegam fora de ordem. Para evitar que o mesmo pagamento seja processado duas vezes ou que uma compensação seja aplicada em duplicidade, cada microsserviço precisa ser rigorosamente idempotente. Isso significa projetar as operações para que possam ser executadas várias vezes produzindo exatamente o mesmo resultado final no banco de dados.

O uso de chaves de idempotência únicas geradas pelo cliente no início da requisição, combinado com o versionamento otimista de registros, permite que o serviço ignore mensagens duplicadas com segurança. Além disso, monitorar gargalos de rede e quedas de conexão é vital para evitar falsos positivos; caso queira aprofundar esse aspecto de resiliência em conexões persistentes, vale conferir os conceitos discutidos em por que conexões WebSocket caem e como garantir resiliência em ambientes distribuídos de alta carga.

Considerações finais sobre resiliência em sistemas distribuídos

Projetar microsserviços resilientes exige uma mudança fundamental de mentalidade: aceitar que falhas na rede, lentidões temporárias e inconsistências transitórias são normais e esperadas em larga escala. O padrão Saga não elimina a complexidade inerente aos sistemas distribuídos, mas fornece um arcabouço estruturado para gerenciá-la de forma previsível e segura. Ao combinar transações compensatórias bem desenhadas, idempotência rigorosa e uma estratégia clara de monitoramento de fluxo, equipes de engenharia conseguem construir plataformas altamente escaláveis capazes de absorver falhas parciais sem corromper o núcleo do negócio.