A Saga do Ingresso Perfeito: Parte 5 (O Toque Final)

O Toque Final

O papel do Webhook para entregar a resposta definitiva ao Lucas.

No episódio anterior, a equipe de engenharia implementou a coreografia perfeita usando o padrão SAGA. Graças a isso, os serviços de Ingressos e Pagamentos conversam de forma assíncrona e resiliente. O banco de dados não fica travado e o assento temporário do Lucas pode ser liberado automaticamente caso ocorra alguma falha na transação financeira.

Ao clicar em "Comprar", o celular do Lucas recebeu imediatamente uma resposta com o status HTTP 202 (Accepted). Essa resposta indica que o pedido foi recebido com sucesso e que o processamento real da SAGA ocorrerá em segundo plano. Mas agora resta o toque final do nosso quebra-cabeça: como a aplicação do celular do Lucas descobre que o ingresso foi finalmente gerado sem precisar travar a tela dele?

O Problema do Polling (O "Já chegou?")

Uma primeira abordagem para resolver isso seria fazer a aplicação cliente realizar consultas repetidas ao servidor de tempos em tempos, técnica conhecida como polling. De segundo em segundo, o celular do Lucas enviaria uma requisição HTTP perguntando: "O ingresso do Lucas já está pronto?".

Embora essa estratégia seja simples de programar, ela traz sérios problemas de escala:

1. Desperdício de Recursos: O celular consome bateria e dados de rede enviando requisições que, na maioria das vezes, receberão um "Ainda não" como resposta.
2. Sobrecarga no Servidor: Multiplicar esse comportamento por milhões de fãs acessando a bilheteria simultaneamente gera uma quantidade enorme de tráfego desnecessário e ineficiente para a infraestrutura.

A Solução: Webhooks (Não me ligue, eu te ligo!)

Para fechar o ciclo assíncrono de maneira elegante, a arquitetura moderna utiliza os Webhooks.

Um Webhook é uma técnica que permite ao servidor enviar dados em tempo real para outras aplicações por meio do protocolo HTTP, agindo assim que a informação fica disponível. Em vez de o cliente gastar recursos perguntando se a transação terminou (modelo de atração ou pull), o servidor toma a iniciativa de avisar o cliente assim que o evento ocorre (modelo de empurrão ou push).

Na prática, o fluxo do Webhook do Lucas funciona da seguinte forma:

1. Registro do Callback: Ao iniciar a compra, a aplicação do Lucas fornece ao servidor uma URL de callback (um endereço de retorno).
2. Processamento em Segundo Plano: O usuário pode continuar navegando no aplicativo enquanto a SAGA (Ingressos -> Pagamentos -> Notificações) é executada de forma invisível no servidor.
3. A Notificação Real-Time: Assim que o Serviço de Notificação consome o evento de sucesso da SAGA, o servidor executa uma requisição HTTP POST contendo os dados do ingresso diretamente para a URL de callback que o celular do Lucas registrou.
4. Atualização da Tela: Ao receber essa chamada POST do servidor, a aplicação do celular do Lucas processa os dados e atualiza instantaneamente a tela com o ingresso confirmado e o QR Code na tela.

Figura 6: Comparação de eficiência entre Polling e Webhooks.

Essa abordagem com Webhooks é amplamente utilizada no mercado por grandes gateways de pagamento, como o Stripe e o PayPal, para notificar de forma segura e em tempo real as plataformas de e-commerce sobre a confirmação de compras.

Com os Webhooks, Lucas finalmente consegue o seu ingresso de forma garantida, sem travamentos e com a melhor experiência de usuário possível.

O site de ingressos agora é resiliente, escalável e assíncrono! Mas como os engenheiros monitoram a saúde de todas essas partes móveis para garantir que o sistema não tenha "pontos cegos" de falha no meio do show?