Consistência Eventual com Sagas Orquestradas em Microsserviços

O Desafio das Transações Distribuídas em Arquiteturas Modernas

Quando dividimos um sistema monolítico gigante em vários microsserviços menores, cada pedaço da aplicação ganha seu próprio banco de dados independente. Na prática, isso significa que não podemos mais usar os recursos tradicionais de banco de dados para garantir que duas operações em serviços diferentes aconteçam ao mesmo tempo ou falhem juntas. Se a primeira etapa funciona, mas a segunda falha por falta de conexão, o sistema fica com um dado inconsistente — o dinheiro sai da conta de um cliente, mas nunca chega ao destino.

Em sistemas legados, o comando 'commit' garantia que tudo fosse salvo de uma vez só. No mundo distribuído moderno, essa facilidade desaparece porque manter conexões abertas entre múltiplos servidores degrada a performance e aumenta o risco de travamentos. É exatamente aqui que entra o conceito de consistência eventual, que garante que os dados em diferentes serviços vão se alinhar com o tempo, mesmo que fiquem dessincronizados por alguns milissegundos ou segundos durante o processo.

Entendendo o Padrão Saga para Coordenar Operações

O padrão saga é uma solução arquitetural que quebra uma grande operação de negócio em uma série de etapas menores e locais. Cada microsserviço executa sua tarefa de forma isolada, salva o resultado em seu próprio banco de dados e em seguida emite um sinal avisando que o trabalho foi concluído. Na prática, imagine uma linha de montagem de carros: a primeira estação instala o motor e avisa a próxima, que coloca as rodas, e assim por diante.

Se qualquer uma das etapas falhar no meio do caminho, o sistema precisa reagir de forma inteligente. Como não existe um comando mágico para desfazer tudo automaticamente, a saga utiliza o conceito de transações compensatórias. Em termos simples, para cada ação realizada, criamos uma operação inversa — se a etapa de pagamento falhou, a compensação devolve o saldo para a carteira do usuário, desfazendo o estrago passo a passo.

Saga Orquestrada versus Coreografia Descentralizada

Existem duas maneiras principais de implementar o padrão saga: a coreografia e a orquestração. Na coreografia, cada microsserviço escuta o que os outros estão fazendo e decide sozinho qual é o próximo passo, como músicos tocando sem um maestro. Embora pareça simples no começo, essa abordagem vira uma caixa preta difícil de depurar quando o sistema cresce e dezenas de serviços começam a trocar mensagens simultaneamente.

A saga orquestrada, por sua vez, introduz um componente central conhecido como orquestrador. Na prática, este componente funciona como o diretor de uma peça de teatro, controlando explicitamente a ordem de execução, chamando cada serviço na hora certa e registrando o progresso em um banco de dados próprio. Se algo der errado, o orquestrador sabe exatamente quais etapas já foram concluídas e aciona os procedimentos de reversão na ordem correta.

Implementando um Orquestrador na Prática com Código

Para ilustrar como funciona o controle centralizado, podemos estruturar um fluxo simples em Python simulando o processo de um pedido de e-commerce. O orquestrador recebe a solicitação inicial e chama sequencialmente os serviços de estoque, pagamento e entrega, tratando exceções caso algum deles retorne um erro.

class OrderOrchestrator:
    def __init__(self, inventory_service, payment_service, shipping_service):
        self.inventory = inventory_service
        self.payment = payment_service
        self.shipping = shipping_service

    def execute_order(self, order_id, items):
        try:
            self.inventory.reserve(items)
            self.payment.charge(order_id)
            self.shipping.schedule(order_id)
            print('Pedido concluído com sucesso!')
        except Exception as e:
            print(f'Falha no fluxo: {e}. Iniciando compensação...')
            self.rollback(order_id, items)

    def rollback(self, order_id, items):
        self.payment.refund(order_id)
        self.inventory.release(items)
        print('Transações compensatórias executadas com sucesso.')

No exemplo acima, a classe central coordena o sucesso ou a falha das chamadas externas. Se a etapa de entrega falhar, o bloco de exceção captura o erro e chama imediatamente os métodos de reembolso e liberação de estoque, garantindo que o estado global do sistema volte a ser seguro.

Tratando Falhas de Rede e Idempotência

Em sistemas distribuídos, mensagens podem se perder, chegar duplicadas ou demorar mais do que o esperado devido à instabilidade da rede. Para evitar que um comando de pagamento seja executado duas vezes por engano, precisamos garantir a idempotência — a propriedade que assegura que uma operação pode ser repetida várias vezes sem alterar o resultado final após a primeira execução bem-sucedida.

Na prática, isso é resolvido gerando um identificador único para cada requisição, conhecido como chave de idempotência. Quando o serviço de pagamento recebe uma ordem com o mesmo identificador pela segunda vez, ele simplesmente ignora a nova cobrança e retorna o recibo anterior armazenado no cache. Sem essa proteção mecânica, qualquer queda momentânea de rede transformaria uma saga automatizada em um pesadelo financeiro.

Considerações Finais sobre Consistência Eventual

Adotar consistência eventual e sagas orquestradas exige uma mudança profunda na mentalidade de engenharia de software. Abandonamos a ilusão de que bancos de dados totalmente isolados podem se comportar como uma unidade monolítica perfeita. Em troca dessa complexidade inicial, ganhamos uma escalabilidade massiva, resiliência contra quedas parciais de servidores e a liberdade de evoluir cada microsserviço de forma independente.

Ao planejar sua próxima arquitetura distribuída, lembre-se de que a simplicidade operacional vale mais do que dogmas acadêmicos. Comece mapeando claramente os fluxos de negócio, desenhe as compensações antes de escrever o código de sucesso e invista em observabilidade para rastrear cada passo da sua saga em tempo real.