Marcio Cunha

Microsserviços sem sincronia? Como usar o Saga Pattern com Kafka

Descubra como coordenar transações distribuídas baseadas em eventos em sistemas desacoplados usando o Saga Pattern e o Apache Kafka sem perder dados.

Marcio Cunha•4 min
Também disponível em:EnglishEspañol
Resumo
  • Transações distribuídas em microsserviços exigem consistência eventual em vez de bloqueios rígidos
  • O padrão Saga substitui o controle centralizado por uma coreografia ou orquestração baseada em eventos
  • O Apache Kafka atua como barramento resiliente para propagar mensagens e garantir a ordem dos eventos
  • Transações compensatórias desfazem ações anteriores quando um erro ocorre em etapas avançadas do fluxo
  • Sistemas desacoplados melhoram a resiliência operacional, mas exigem tolerância à assincronicidade

Por que microsserviços modernos rejeitam o bloqueio de banco de dados

Quando se divide um sistema monolítico em vários microsserviços, cada componente ganha seu próprio banco de dados isolado. Na prática, isso significa que operações complexas, como fechar uma compra que envolve estoque, pagamento e faturamento, deixam de acontecer em uma única transação atômica do banco de dados tradicional. Tentar travar todas essas tabelas ao mesmo tempo pela rede criaria gargalos insuportáveis e falhas em cascata. É por essa razão que sistemas modernos precisam abraçar a consistência eventual, aceitando que os dados demoram alguns milissegundos para se alinharem em toda a rede. Se você quer entender melhor os desafios por trás desse modelo, vale a pena conferir nosso artigo sobre como garantir consistência em arquiteturas event-driven.

O que é o Saga Pattern e como ele resolve transações divididas

O Saga Pattern é uma sequência de transações locais onde cada microsserviço atualiza seus dados e publica um evento ou mensagem. Na prática, o sistema avança etapa por etapa: o serviço de pedidos cria a ordem e avisa os demais, o de pagamento cobra o cliente, e o de estoque separa o produto. Se tudo correr bem, o processo termina com sucesso. Contudo, se o pagamento for recusado no meio do caminho, a Saga não tenta dar um 'rollback' mágico que desfaz tudo instantaneamente no disco. Em vez disso, ela executa transações compensatórias, ou seja, ações que revertem o efeito da etapa anterior de forma lógica, como liberar novamente o estoque que havia sido reservado.

Coreografia versus Orquestração: qual escolher no Apache Kafka

Existem duas formas principais de implementar o padrão Saga: coreografia e orquestração. Na coreografia, cada microsserviço escuta os eventos do Kafka, executa sua lógica e publica um novo evento por conta própria, funcionando como uma dança onde cada dançarino reage ao movimento do outro. Na orquestração, existe um componente centralizador que envia comandos diretos para cada serviço e monitora o progresso de toda a jornada. Para fluxos complexos com dezenas de etapas, a orquestração costuma evitar que o sistema vire uma caixa preta difícil de depurar. Independentemente da escolha, o uso de barramentos eficientes é indispensável, dialogando diretamente com boas práticas discutidas em como desenhar arquiteturas Event-Driven sem perder transações.

Garantindo resiliência e ordem de eventos com o Apache Kafka

O Apache Kafka funciona como o sistema nervoso central dessa arquitetura, armazenando os eventos em tópicos particionados. Na prática, cada chave de particionamento, como o ID do pedido, garante que os eventos cheguem na ordem exata em que foram gerados para aquele cliente específico. Se um microsserviço ficar offline temporariamente por causa de uma queda de rede ou reinicialização, ele não perde nenhuma mensagem. Assim que o serviço volta ao ar, ele retoma o consumo do tópico do ponto exato onde parou, processando a compensação ou a continuidade da Saga sem intervenção manual. Essa robustez operacional é fundamental para evitar estados inconsistentes no negócio.

Lidando com falhas parciais e transações compensatórias na prática

Desenvolver transações compensatórias exige cuidado redobrado com a idempotência, que é a capacidade de executar a mesma operação várias vezes sem alterar o resultado final. Imagine que um evento de compensação seja entregue duas vezes por causa de uma duplicidade na rede; se a operação não for idempotente, o estoque poderá ser estornado em dobro por engano. Para evitar esse tipo de dor de cabeça, cada microsserviço deve registrar chaves de idempotência em suas tabelas internas antes de processar qualquer comando do Kafka. Assim, mensagens duplicadas são ignoradas de forma segura, mantendo a integridade financeira e operacional de todo o ecossistema distribuído. Para aprofundar esses conceitos na prática em produção, confira também nossa análise técnica sobre IA gerando código inseguro? Como usar AST para varredura.

Considerações finais sobre consistência eventual e sistemas desacoplados

Adotar o Saga Pattern com Kafka transforma radicalmente a forma como encaramos a confiabilidade no desenvolvimento de software. Embora exija uma mudança de mentalidade — abandonando a ilusão de que tudo acontece instantaneamente —, o ganho em escalabilidade e autonomia dos times compensa cada linha extra de código de compensação. O segredo está em desenhar os fluxos pensando sempre no pior cenário possível, garantindo que o sistema saiba se recuperar sozinho quando algo der errado no meio do caminho.