A Saga do Ingresso Perfeito: Parte 4 (O Padrão SAGA e Ações Compensatórias)

A Saga dos Ingressos

Coreografia, Eventos e como desfazer problemas sem transações ACID.

No episódio anterior, deixamos o Lucas em um momento de suspense. Ele clicou em "Comprar", o Serviço de Ingressos reservou o assento temporariamente, mas o Serviço de Pagamentos encontrou um problema: o cartão dele foi recusado. Como cada microserviço possui seu próprio banco de dados isolado (seguindo a regra de ouro do shared-nothing), não podemos usar um ROLLBACK tradicional de banco de dados que cruze a rede para liberar o assento.

Se tentássemos usar transações distribuídas clássicas (como o protocolo Two-Phase Commit ou 2PC), bloquearíamos os bancos de dados dos serviços durante a comunicação de rede, destruindo a escalabilidade e a tolerância a falhas do sistema de vendas. Para resolver isso de forma altamente escalável, os sistemas modernos utilizam o Padrão SAGA.

O que é o Padrão SAGA?

Uma SAGA é um padrão de design de software que gerencia transações distribuídas por meio de uma sequência de transações locais. Em vez de tentar travar todo o sistema em uma única grande transação síncrona, cada microserviço executa sua própria transação local no seu banco de dados e publica um evento no broker de mensagens para avisar os outros serviços sobre o resultado do seu processamento.

Se todos os passos da SAGA tiverem sucesso, a transação distribuída é concluída e o sistema alcança a consistência eventual. Mas se um dos passos falhar (como o pagamento recusado do Lucas), a SAGA precisa dar um passo para trás e "limpar a bagunça". É aqui que entram as Ações Compensatórias.

Ações Compensatórias: O "Desfazer" Distribuído

Em sistemas distribuídos eventualmente consistentes, se não podemos reverter a transação de forma física e imediata com um rollback, nós precisamos rolar para a frente criando novas transações de correção. Uma ação compensatória é uma transação local explícita cujo objetivo é desfazer o efeito de uma transação local que foi executada anteriormente com sucesso.

No caso do Lucas:

1. O Serviço de Ingressos cria a reserva temporária (sucesso).
2. O Serviço de Pagamentos tenta cobrar o cartão e falha (erro).
3. A SAGA entra em ação para corrigir o estado do sistema: o Serviço de Ingressos executa uma ação compensatória para cancelar a reserva e liberar o assento "A-12" no seu banco de dados local.

SAGA Baseada em Coreografia

Existem duas formas principais de coordenar uma SAGA: Orquestração (onde um serviço central controla o fluxo) e Coreografia (onde os serviços agem de forma autônoma e reagem a eventos). Para o nosso sistema de ingressos, a Coreografia é uma escolha elegante porque mantém os serviços altamente desacoplados e resilientes.

Na coreografia, nenhum serviço central dita as regras. Em vez disso, os microserviços "dançam" de forma coordenada reagindo aos eventos publicados no broker de mensagens. Veja como fica o desenho dessa dança:

Figura 5: O fluxo do Padrão SAGA Coreografada para Ingressos e Pagamento.

O Fluxo Passo a Passo da Coreografia do Lucas:

Lucas inicia a compra: O Serviço de Ingressos grava a reserva temporária no banco local e publica o evento ReservaCriada no broker.

O pagamento falha: O Serviço de Pagamentos consome o evento ReservaCriada, tenta processar o pagamento com a operadora do cartão e falha. Ele grava o status de falha no seu próprio banco e publica o evento PagamentoRecusado.

A compensação acontece: O Serviço de Ingressos (que está escutando o tópico de pagamentos) recebe o evento PagamentoRecusado. Ele entende que a compra falhou e executa a sua ação compensatória: altera o status do assento de "Reservado" para "Disponível" no seu banco local.

O cliente é notificado: O Serviço de Notificações também consome o de PagamentoRecusado e prepara um e-mail ou alerta para avisar o Lucas de que a compra não pôde ser concluída.

Graças à SAGA coreografada, o sistema de ingressos se mantém resiliente e os bancos de dados nunca ficam travados esperando por respostas síncronas de rede. O Lucas é avisado do problema de forma elegante, e o assento "A-12" é imediatamente liberado para o próximo fã na fila, sem qualquer intervenção manual.

Mas espere um pouco! Se o pagamento do Lucas tivesse dado certo e a SAGA terminasse com sucesso, como a aplicação do celular do Lucas (que iniciou tudo de forma assíncrona) saberia que o processo terminou para atualizar a tela dele com o ingresso comprado?

No próximo episódio, veremos como fechar esse ciclo de comunicação assíncrona utilizando os poderosos Webhooks.