Persistência Poliglota e Transações Distribuídas com o Padrão Saga Baseado em Coreografia

O Desafio da Consistência de Dados em Sistemas Distribuídos

Quando dividimos um sistema monolítico gigante em vários microsserviços menores, cada pedaço do software ganha seu próprio banco de dados. Na prática, isso significa que podemos usar um banco relacional tradicional para o cadastro de clientes e um banco orientado a documentos para o catálogo de produtos. Essa abordagem, conhecida como persistência poliglota, traz uma grande flexibilidade tecnológica, mas cria um quebra-cabeça complexo: como garantir que uma compra seja concluída com sucesso se o estoque está em um servidor, o pagamento em outro e a entrega em um terceiro?

Em aplicações tradicionais, usamos transações atômicas — aquelas que garantem que tudo acontece junto ou nada é salvo. Se houver um erro, o sistema desfaz tudo com um comando chamado rollback. No entanto, quando os dados estão espalhados por servidores diferentes e redes distintas, esse mecanismo tradicional deixa de funcionar. Travar todos esses bancos ao mesmo tempo causaria lentidão extrema e tornaria o sistema frágil. É nesse cenário que precisamos adotar novas formas de pensar a integridade dos dados, aceitando que a consistência pode acontecer de forma gradual, ou seja, em alguns instantes após o evento principal.

Entendendo o Padrão Saga para Operações em Cadeia

O padrão Saga resolve o problema das transações distribuídas dividindo uma operação complexa em uma sequência de passos locais. Cada microsserviço executa sua própria transação no seu próprio banco e publica um aviso dizendo que o trabalho foi concluído. Na prática, uma Saga funciona como uma linha de montagem em uma fábrica: a primeira estação monta a peça, avisa a próxima, que por sua vez faz o seu trabalho e passa adiante, até o produto final ficar pronto.

Se todas as etapas ocorrerem sem problemas, a operação é finalizada com sucesso. Mas e se o pagamento falhar na última etapa? Como já passamos pelos passos anteriores, precisamos de um mecanismo para voltar atrás. É aí que entram as transações compensatórias. Na prática, a compensação é uma ação de sentido inverso: se o sistema reservou um item no estoque e o pagamento falhou, a transação compensatória devolve esse item para o estoque. Dessa forma, mantemos o equilíbrio do sistema sem precisar travar dados por minutos ou horas.

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

Existem duas maneiras principais de implementar o padrão Saga: por orquestração ou por coreografia. Na orquestração, existe um componente central — um maestro — que diz a cada serviço o que fazer e quando fazer. Já na coreografia, que é o foco deste artigo, não existe chefe. Cada serviço escuta o que acontece no ambiente e reage por conta própria, como músicos tocando em uma banda sem um maestro regendo cada nota em tempo real.

Na coreografia, a comunicação acontece por meio de barramentos de eventos, como ferramentas de mensageria (ex: Apache Kafka ou RabbitMQ). Quando o serviço de pedidos cria um novo pedido, ele apenas publica um evento chamado PedidoCriado. O serviço de estoque ouve esse evento, reserva o produto e publica outro evento, como EstoqueReservado. O serviço de pagamento escuta esse segundo evento, processa o cartão e avisa a rede. Essa descentralização reduz o acoplamento entre os serviços, tornando a arquitetura mais flexível, embora exija disciplina para rastrear o fluxo completo dos dados.

// Exemplo de evento publicado pelo serviço de pedidos em um barramento de mensagens
{
  "eventId": "evt_987654321",
  "eventType": "PedidoCriado",
  "timestamp": 1672531200,
  "payload": {
    "orderId": "ord_123",
    "customerId": "usr_456",
    "totalAmount": 150.00,
    "currency": "BRL"
  }
}

Garantindo a Confiabilidade com Idempotência e Rastreabilidade

Trabalhar com mensagens assíncronas em redes reais significa que mensagens podem se perder, atrasar ou chegar duplicadas. Para evitar que um cliente seja cobrado duas vezes por causa de uma mensagem duplicada, os serviços precisam ser idempotentes. Na prática, idempotência significa que executar a mesma ação dez vezes tem o mesmo efeito prático de executá-la apenas uma vez. Se o sistema receber um evento de pagamento já processado, ele deve ignorar a duplicata com segurança com base em um identificador único.

Outro ponto crítico é a observabilidade. Como não há um maestro central controlando a Saga, rastrear onde um erro aconteceu pode ser difícil se não desenharmos o sistema com cuidado. Usamos identificadores de correlação, que são códigos únicos que acompanham todas as mensagens geradas a partir de uma mesma ação do usuário. Ao centralizar os logs e métricas dessas mensagens em ferramentas de monitoramento, conseguimos enxergar o caminho completo que o dado percorreu, facilitando a depuração e a auditoria operacional.

Considerações Finais sobre Arquiteturas Orientadas a Eventos

A adoção do padrão Saga baseado em coreografia representa uma mudança profunda na mentalidade de engenharia de software, exigindo que equipes abandonem a dependência de transações locais instantâneas. Embora traga complexidade operacional inicial e exija testes rigorosos de cenários de falha, os benefícios compensam amplamente o esforço em sistemas de alta escala. Ao garantir o desacoplamento e a resiliência por meio de eventos reativos, as organizações conseguem escalar seus microsserviços de forma independente, mantendo a integridade dos dados mesmo em ambientes altamente distribuídos.