Quais são as considerações de implementação para produtores de webhooks

Webhooks são usados para integrar aplicações em rede com o objetivo principal de transferir informação. Quando a aplicação A precisa se comunicar com a aplicação B, A gera um webhook e o envia para B por meio de uma requisição HTTP. Essa é uma comunicação unidirecional e, muitas vezes, do tipo fire-and-forget, que termina assim que o webhook é recebido pela aplicação de destino. A aplicação que envia o webhook é chamada de produtor de webhooks, enquanto a aplicação que recebe é chamada de consumidor de webhooks.

Em ambientes de produção, essa comunicação não é tão simples quanto acabei de descrever. Tanto produtores quanto consumidores de webhooks precisam de certas características de desempenho e tolerância a falhas para funcionar de forma ideal e confiável.

Neste artigo, o foco são os produtores de webhooks. Vamos ver os pontos importantes a considerar ao trabalhar com produtores, como melhorar o tempo de resposta e o que podemos fazer para escalar essa operação.

O que são produtores de webhooks?

Produtores de mensagens geram e disparam requisições de webhook em reação a um evento que acontece no sistema da aplicação de origem. Por exemplo, um webhook pode ser configurado para ser disparado quando uma compra é feita em uma aplicação de e-commerce como o Shopify (ou em uma aplicação de e-commerce própria).

Quando o evento ocorre, uma requisição de webhook é gerada e enviada para uma aplicação de destino. Durante a configuração do webhook, um endpoint na aplicação de destino é definido como alvo da requisição. Essa URL é conhecida como webhook URL.

Depois que o webhook é enviado, o produtor espera uma resposta do consumidor. Dependendo da resposta, o produtor pode confirmar que o webhook foi consumido, tentar reenviá-lo ou simplesmente esquecê-lo.

Como os produtores de webhooks definem um limite rígido para o tempo de resposta, a boa prática recomendada é processar webhooks de forma assíncrona. Uma das maneiras mais comuns de implementar processamento assíncrono para webhooks é usar um middleware de filas de mensagens (frequentemente chamado de message broker).

A maioria dos message brokers não fala o protocolo HTTP. Então, para usar um broker com um produtor de webhooks, é necessário um gateway de API que converta as mensagens de HTTP para o protocolo compatível com o broker escolhido.

Na próxima seção, vamos ver como tornar essa configuração assíncrona confiável para os nossos webhooks.

Quais são as considerações de implementação ao lidar com produtores de webhooks?

Nesta seção, vamos ver as informações e considerações que precisamos levar em conta ao trabalhar com produtores de webhooks. Na maior parte do tempo, como acontece com produtores de terceiros como Stripe e Shopify, não teremos controle total sobre como os webhooks são gerados e disparados.

Entender como o webhook é disparado, assim como a natureza, o formato e a estrutura da requisição, é fundamental para tratá-lo corretamente.

Vamos ver alguns desses fatores importantes.

• Protocolo da requisição: webhooks são enviados usando o protocolo HTTP, mas você precisa saber se o webhook usa estritamente HTTPS ou uma mistura dos dois (embora isso seja raro). Como endpoints HTTPS aceitam requisições HTTP e HTTPS, o gateway de API precisa expor um endpoint HTTPS para os seus produtores de webhooks.
• Método da requisição: o endpoint do seu gateway de API precisa suportar o método pelo qual os webhooks são enviados. Pela minha experiência com webhooks, quase todos os provedores (de terceiros) com os quais trabalhei usam o método POST. Você pode expor um endpoint que suporte tanto POST quanto GET se for receber uma mistura dos dois tipos de requisição.
• Retries automáticos e/ou manuais: alguns provedores têm sistemas de retry (manual, automático ou ambos) embutidos. Um sistema de retry ajuda a reenviar um webhook quando ele falha do lado do consumidor. Entender quão confiável é o sistema de retry de um provedor (se é que existe) e como ele opera ajuda a decidir se você deve construir o seu próprio sistema de retry na sua infraestrutura de webhooks e quão elaborado ele precisa ser.
• Timeout da requisição: como dito antes, produtores de webhooks definem um limite rígido de timeout para cada webhook. O tempo de resposta de cada webhook que chega ao seu gateway deve estar sempre abaixo desse valor, não importa quantos webhooks concorrentes o gateway precise processar. Por exemplo, se o timeout de cada webhook é de 5 segundos, o tempo de resposta do gateway não deve ser de 4 segundos por webhook. É importante ficar abaixo do limite de timeout do produtor mesmo à medida que o número de webhooks concorrentes cresce.
• Formato e estrutura da mensagem: o formato (JSON ou XML) e a estrutura da mensagem do webhook precisam ser considerados na forma como ele é tratado dentro do gateway de API. Você também precisa entender a estrutura do payload e dos headers do webhook para fazer as transformações necessárias, como adicionar um Trace ID à requisição para fins de monitoramento.
• Verificação: alguns provedores exigem que o cliente passe por um processo de verificação antes de acessar a informação do webhook. Um processo comum de verificação envolve criptografia simétrica com uma chave secreta, muitas vezes usando verificação de assinatura SHA256. Se a verificação for necessária, o gateway de API precisa receber todas as informações necessárias para passar por ela. Você também pode optar por delegar a responsabilidade da verificação aos consumidores.

Quais são as considerações de escalabilidade ao lidar com a carga de um produtor de webhooks?

Um dos requisitos de uma infraestrutura de webhooks confiável é a capacidade de continuar adicionando instâncias do mesmo tipo de produtor e escalar com um número crescente de produtores. Por exemplo, imagine que você tem um serviço de pagamentos que processa pagamentos para a sua loja Shopify. A loja envia um webhook para o serviço de pagamentos quando uma compra é feita. Vamos supor que o negócio cresça e você precise criar mais lojas Shopify para clientes de outros continentes ou países. Em vez de apenas uma, agora você tem várias instâncias de loja Shopify enviando webhooks para o mesmo serviço de pagamentos.

O primeiro passo é garantir que os produtores estejam completamente desacoplados dos consumidores. Isso significa que os produtores não devem saber onde os consumidores estão nem como eles operam. O nosso gateway de API já cuida disso, sendo o único destino para o qual os produtores direcionam suas requisições de webhook. Os detalhes de como o gateway trata os webhooks também ficam abstraídos do produtor. Tudo o que um produtor faz é enviar uma requisição de webhook e receber uma resposta de sucesso dentro do seu limite de timeout. A partir daí, o trabalho dele está feito.

O segundo passo é colocar um load balancer entre os seus produtores de webhooks e um pool de servidores de gateway de API. Isso permite distribuir o volume de webhooks recebidos dos produtores entre essas instâncias de gateway. Com essa configuração, você melhora o tempo de resposta das requisições de webhook e a confiabilidade geral da sua infraestrutura.

À medida que o volume de webhooks continua aumentando, outro componente da configuração assíncrona que pode ficar sobrecarregado é o message broker. Felizmente, cada tecnologia de broker permite implantar várias instâncias em um cluster. Isso ajuda a aumentar a ingestão de webhooks, já que há mais filas para escrever. O tamanho das filas dos brokers não é facilmente excedido, há mais sockets de rede disponíveis e o throughput das filas melhora.

Conclusão

Produtores de webhooks são a origem dos webhooks com os quais a sua infraestrutura vai ter que lidar e, por isso, escalar a sua infraestrutura para lidar com webhooks começa pelos produtores. Neste artigo, você viu como escalar produtores de webhooks começa por desacoplá-los dos consumidores e ingerir os webhooks em uma fila de mensagens, passando por um gateway de API para processamento assíncrono. Você também aprendeu todos os fatores importantes que precisam ser levados em conta ao desenhar a sua estratégia de processamento assíncrono.

Esses fatores e boas práticas de implementação não são exaustivos, mas dão um ótimo ponto de partida para escalar os seus produtores de webhooks.

Bons códigos!