Por que você deveria parar de processar seus webhooks de forma síncrona

No artigo anterior, concluímos que precisamos construir recursos de resiliência e observabilidade em torno dos nossos webhooks. Também discutimos como a arquitetura orientada a eventos encaixa melhor as características de resiliência no pipeline da infraestrutura de webhooks.

Este artigo explica com mais profundidade por que a arquitetura orientada a eventos é a resposta para os nossos problemas de resiliência com webhooks, como chegar a essa arquitetura usando filas e quais dores as filas ajudam a eliminar.

Por que o processamento assíncrono é recomendado ao lidar com eventos

Um webhook empacota um evento em uma requisição HTTP para comunicá-lo a outra aplicação ou componente remoto, o que faz parecer natural tratá-lo no estilo tradicional de comunicação requisição-resposta (cliente/servidor).

No entanto, do ponto de vista arquitetural, a abordagem recomendada é o estilo assíncrono da arquitetura orientada a eventos. O processamento assíncrono implementa um modelo de confirmar primeiro, processar depois que permite escalar seus webhooks sob cargas pesadas e lidar com erros de forma mais elegante.

Se você é novo no estilo de processamento assíncrono ou precisa de uma introdução, veja o nosso artigo “Introduction to Asynchronous Processing”.

Para reforçar essa afirmação, vamos comparar a experiência de tratar webhooks com a abordagem síncrona do modelo baseado em requisições com a abordagem assíncrona da arquitetura orientada a eventos.

Timeouts de requisição

Espera-se que requisições HTTP sejam processadas antes de a resposta ser enviada. Se o limite de tempo de resposta for ultrapassado, a requisição do webhook sofre timeout. Quando isso acontece, o provedor do webhook assume que a entrega falhou e acaba descartando o evento.

Abordagem síncrona

Na abordagem síncrona cliente/servidor, o provedor do webhook precisa esperar o processamento terminar antes de receber uma resposta.

Tempo de resposta = latência da requisição + tempo de processamento

Isso aumenta muito o tempo de resposta e a chance de um webhook ser descartado.

Abordagem assíncrona

Já em um estilo arquitetural orientado a eventos, os eventos são confirmados imediatamente e depois colocados em fila para serem processados quando o consumidor estiver pronto. Assim, o tempo de resposta passa a ser:

Tempo de resposta = latência da requisição

Isso permite que os consumidores respondam aos produtores o mais rápido possível, reduzindo drasticamente a possibilidade de timeouts.

Back pressure

Back pressure acontece quando há tantas requisições simultâneas que a capacidade do servidor é ultrapassada.

Abordagem síncrona

Essa situação satura o pool de conexões e faz a fila de requisições crescer, deixando as requisições mais novas sujeitas a serem descartadas por causa dos tempos de resposta longos.

Abordagem assíncrona

Em um sistema baseado em eventos, as requisições não correm o risco de serem descartadas, porque o produtor do webhook já recebeu uma resposta assim que o consumidor confirmou o recebimento.

Recuperação de falhas

É a capacidade de se recuperar de uma falha na arquitetura durante o envio e o processamento de webhooks.

Abordagem síncrona

Em um modelo típico baseado em requisições HTTP, o cliente carrega boa parte da responsabilidade de garantir que a requisição seja processada com sucesso. Assim, quando uma requisição falha, o cliente faz um retry ou envia uma notificação que pode disparar um retry. O cliente, humano ou máquina, que inicia a requisição conhece a importância dela.

Já em um estilo de comunicação fire-and-forget de webhooks, o provedor que dispara o webhook prioriza a entrega em vez da recuperação de erros.

Abordagem assíncrona

A arquitetura orientada a eventos trata a resiliência e prioriza o tratamento e a recuperação de erros ao persistir temporariamente os eventos até que sejam processados com sucesso.

Perda de dados

É a situação em que a informação sobre um evento não pode mais ser recuperada por causa de uma falha no sistema.

Abordagem síncrona

Quando uma requisição falha em um modelo típico baseado em requisições HTTP, o servidor não guarda nenhum registro dela. A única forma de obter a informação é se o cliente fizer um retry. Se a requisição não for repetida e processada com sucesso, ela pode se perder para sempre.

Suponha que o sucesso da requisição seja a diferença entre ter um cliente satisfeito que volta ou um cliente frustrado e irritado. Nesse caso, essa perda de dados torna quase impossível reverter a situação.

Abordagem assíncrona

O estilo assíncrono da arquitetura orientada a eventos permite a persistência temporária dos dados do evento até que ele seja processado com sucesso.

Essa capacidade ajuda você a se recuperar de falhas transitórias que poderiam causar impactos graves se não fossem contornadas.

Para entender por que a arquitetura orientada a eventos é tão útil no tratamento de webhooks, primeiro precisamos entender como os webhooks são eventos.

Webhooks são eventos

Até aqui nesta série, enfatizamos consistentemente que os webhooks ajudam a levar informações sobre um evento de uma aplicação ou componente remoto para outro.

Como o webhook sinaliza a ocorrência do evento e contém dados sobre ele, o webhook representa o próprio evento.

Assim, mesmo que os webhooks empacotem o evento em uma requisição HTTP, o melhor é tratar o webhook como um evento.

Vamos ver as semelhanças entre eventos comuns e webhooks.

Com tantas semelhanças, fica claro que webhooks são simplesmente eventos trafegando por outro canal. E, por isso, faz sentido que um estilo arquitetural criado para lidar com aplicações orientadas a eventos seja o mais adequado para processar webhooks.

Por que você deveria começar a usar filas para seus webhooks

Uma das grandes vantagens do estilo arquitetural orientado a eventos, além de introduzir o processamento assíncrono no tratamento dos seus webhooks, é que ele pode ser usado como arquitetura independente ou embutido em uma arquitetura já existente.

Uma das formas mais rápidas de implementar essa arquitetura, especialmente em infraestruturas existentes, é por meio de um sistema de filas.

Colocar uma fila entre os seus provedores de webhooks (Stripe, Shopify, etc.) e o seu servidor introduz imediatamente o processamento assíncrono na sua infraestrutura. A fila faz isso confirmando o recebimento dos webhooks, armazenando-os temporariamente e entregando-os ao seu consumidor em um ritmo que ele consegue suportar.

Sejam tecnologias de fila open source como Kafka e RabbitMQ, sejam serviços gerenciados como Amazon SQS e Google Pub/Sub, as filas ajudam a implementar os recursos de resiliência que as arquiteturas orientadas a eventos promovem.

Vamos ver alguns desses recursos e como as filas nos ajudam a alcançá-los.

Processamento assíncrono

Uma das formas mais rápidas de implementar o processamento assíncrono é adicionar uma fila entre o provedor e o consumidor do webhook.

Um sistema de filas confirma a requisição do webhook e imediatamente a adiciona como mensagem na fila. O consumidor pode então retirar essa mensagem e processá-la.

Retry de webhooks

Às vezes o consumidor encontra uma falha ao tentar processar um webhook. Essas falhas podem vir de problemas transitórios, como quedas do servidor, ou de problemas que exigem correção.

A fila ajuda a persistir a mensagem do webhook para que o consumidor possa retomá-la para processamento quando o problema for resolvido.

Throttling de requisições / rate limiting

Um dos recursos mais valiosos das filas é a capacidade de entregar requisições ao servidor consumidor dentro da capacidade dele. As filas também podem fazer health checks nos seus consumidores e redirecionar ou persistir mensagens quando detectam que um determinado consumidor está fora do ar. Isso ajuda a evitar quedas do servidor por sobrecarga.

Você também pode configurar as filas para entregar mensagens dentro de um limite medido, garantindo que os consumidores não sejam sobrecarregados.

Recuperação em lote

Algumas falhas podem fazer com que um grande número de webhooks falhe no lado do consumidor. Com filas, todos esses webhooks são persistidos e, assim que o problema do consumidor é resolvido, os consumidores retomam automaticamente os webhooks e os processam.

Pelos pontos discutidos acima, fica claro que a fila é um componente essencial para trazer confiabilidade à infraestrutura construída para lidar com webhooks. Basta colocar uma fila entre o provedor e os consumidores de webhooks e todos os recursos de resiliência estarão disponíveis... mas espere, não tão rápido.

Filas não são tão simples de implementar e, como qualquer outro componente novo que você traz para a sua infraestrutura, elas adicionam uma camada extra de complexidade. Primeiro você precisa escolher a tecnologia de filas que melhor se encaixa no seu cenário e, dependendo da escolha, talvez precise construir alguns recursos personalizados em volta dela para atender a todas as boas práticas de resiliência e observabilidade.

Conclusão

Neste artigo, estabelecemos a necessidade de processar nossos webhooks de forma assíncrona para torná-los resilientes.

Também falamos sobre filas e o papel delas na implementação de um padrão orientado a eventos por meio do processamento assíncrono.

O próximo artigo vai focar nos recursos que você deve observar ao escolher uma solução de filas confiável. Discutimos os prós e contras das soluções existentes, além de como escolher a que melhor atende ao seu caso de uso. Também vamos introduzir o lado da observabilidade e mostrar como escolher a melhor solução para o seu cenário.

Bom código!