Introdução aos problemas com webhooks
Webhooks são requisições HTTP disparadas de uma aplicação remota para outra quando um evento acontece. Esse processo de comunicação é detalhado no nosso artigo “O que são webhooks e como eles funcionam”. Em essência, webhooks oferecem um canal de comunicação simples entre diferentes aplicações em um sistema distribuído. Mas, como toda tecnologia “simples”, o problema está nos detalhes.
Na hora da implementação real, webhooks são bastante propensos a falhas. Mesmo com práticas de teste rigorosas, algumas falhas surgem de cenários complexos que só se manifestam em produção.
Causas comuns de falha incluem, mas não se limitam a, pontos únicos de falha, redes instáveis, processos lentos e cargas inesperadas. Embora tenhamos descoberto que a maioria desses problemas pode ser mitigada processando os seus webhooks de forma assíncrona, esta série foca nos diferentes tipos de problemas que você pode enfrentar ao trabalhar com webhooks.
Este artigo é o primeiro de uma série que busca dar a você uma visão aprofundada do universo de problemas encontrados ao usar webhooks em ambientes de produção.
Vamos começar analisando por que esses problemas existem. Depois, vou categorizar os diferentes tipos de problemas enfrentados com webhooks, discutir como a maioria dos times está (atualmente) lidando com eles e recomendar soluções e boas práticas para prevenção e remediação eficaz.
Do desenvolvimento à produção
Então você decidiu usar webhooks. Você tem um provedor que permite informar a URL do endpoint da sua aplicação onde vai receber os webhooks. Você configura o seu webhook com sucesso, recebe o primeiro, sorri e vai embora. Trabalho bem feito… fácil demais.
Mais tarde naquele dia, você checa os seus webhooks e percebe que a sua aplicação foi bombardeada com centenas de eventos irrelevantes e dados de lixo enchendo o seu banco de dados. Aparentemente, qualquer pessoa com acesso à URL do seu webhook pode enviar requisições para a sua aplicação. Você percebe que, diferente daquele teste que rodou com ngrok no ambiente de desenvolvimento, URLs de webhook precisam de autenticação para estarem protegidas em produção.
Então você implementa uma das estratégias de autenticação do seu provedor e respira aliviado de novo.
Mas não demorou muito para você começar a receber e-mails do serviço de monitoramento de erros instrumentado no seu código sobre exceções no banco de dados. Acontece que, a partir de um certo número de webhooks concorrentes, o pool de conexões do seu banco se esgota e ele passa a rejeitar requisições. Algo que você não tinha notado antes de ir para produção porque só testou com alguns poucos webhooks. Então você corrige isso e, mais uma vez, está tudo bem…… ou não?
Algumas semanas se passam sem novidades, e então chega um feriado. Você faz uma grande promoção no seu site, o que leva milhares de clientes a usá-lo no mesmo período. Os seus webhooks crescem exponencialmente, aumentando drasticamente o número de webhooks concorrentes que o seu endpoint precisa processar. Isso mesmo: você tem um pico!
Isso consome rapidamente os recursos do seu servidor, satura o pool de conexões e acaba derrubando o servidor. Você reinicia, mas não demora para as requisições voltarem a disparar, já que o dia inteiro é horário de pico por causa da correria do feriado. Agora o tempo não está do seu lado: negócios estão sendo perdidos e a frustração dos clientes aumenta a cada segundo que o problema persiste.
Pelos cenários que descrevi até aqui, tenho certeza de que está ficando claro que webhooks são frágeis e exigem resiliência construída em torno deles para sobreviver a ambientes de produção. Os cenários acima nem arranham a superfície dos tipos de problema que surgem ao usar webhooks em produção. Mesmo assim, não há motivo para pânico nem para abandonar os webhooks. Esta série é dedicada a equipar você com o conhecimento e as ferramentas necessárias para mitigar esses problemas.
Problemas comuns com webhooks
Pelos nossos anos de experiência no universo dos webhooks, os problemas mais comuns que engenheiros e stakeholders nos trazem incluem frases como:
- Não tenho certeza se os meus webhooks estão funcionando
- Não sei quais webhooks falharam
- Estou recebendo múltiplos webhooks para o mesmo evento
- Por que os meus webhooks estão lentos?
- O meu provedor de webhooks só permite uma URL
- Por que estou recebendo tantos erros de timeout?
- …e mais
Dividimos esses problemas em 4 grandes categorias, apresentadas nas seções abaixo; também vou linkar os artigos correspondentes desta série de problemas e soluções de webhooks.
Cada seção abaixo trata de uma categoria de problema. Vamos ver os diferentes tipos de problema em cada categoria, discutir o problema para entender por que ele acontece e então recomendar soluções.
Testes
Testar é a prática de garantir que você pegue bugs cedo o suficiente, ou seja, antes que os seus webhooks entrem em produção. Quanto mais tempo leva para detectar um bug, mais caro é corrigi-lo. Por isso, os testes são a sua primeira linha de defesa contra problemas com webhooks.
Para saber mais sobre problemas que surgem da ausência ou insuficiência de testes, e as soluções correspondentes, confira o nosso artigo “Problemas e soluções de testes de webhooks”.
Gestão
Os webhooks precisam ser gerenciados de forma eficaz para garantir que se integrem corretamente à sua infraestrutura existente. Muitas vezes, você trabalha com vários webhooks e precisa harmonizar as atividades deles. Os esquemas de autenticação e os payloads também variam de provedor para provedor. Por isso, você precisa coordenar todos os seus webhooks para alcançar o impacto desejado no seu negócio.
Para saber mais sobre problemas que surgem de questões de gestão dentro da sua infraestrutura de webhooks, e as soluções correspondentes, confira o nosso artigo “Problemas e soluções de gestão de webhooks”.
Monitoramento
É óbvio que problemas são inevitáveis ao trabalhar com webhooks. Uma forma de garantir que você está focado em resolver os problemas certos é acompanhar a atividade dos seus webhooks com um monitoramento eficaz.
O monitoramento serve para detectar falhas que afetam os usuários e pode ser usado para disparar alertas ou correções automatizadas. Ele também dá uma visão geral da saúde dos seus webhooks.
Para saber mais sobre problemas de monitoramento de webhooks e as soluções correspondentes, confira o nosso artigo “Problemas e soluções de monitoramento de webhooks”.
Recuperação de erros
Como mencionado na seção anterior, a falha é inevitável. É por isso que você precisa dedicar tanta atenção à recuperação de falhas quanto à prevenção delas.
O nosso artigo de problemas e soluções sobre recuperação de erros lista erros comuns e cenários de recuperação encontrados com webhooks em produção. Nele eu detalho como se recuperar desses erros com mecanismos de autocorreção e ferramentas de investigação que podem ser usadas em ambientes de produção.
A solução atual
Os problemas com webhooks são tão antigos quanto os próprios webhooks e, ao longo dos anos, várias soluções foram desenhadas para mitigar essas dores. Existem soluções para lidar com questões como timeout, erros de código e picos de tráfego.
Abaixo está uma tabela mostrando o “encanamento” usual que entra na mitigação dos problemas em torno dos webhooks.
| Ferramenta | Problema que resolve | Exemplos |
|---|---|---|
| Runtime de ingestão | Lidar com autenticação, transformar payloads, TLS termination etc. | AWS Lambda, Cloudflare Workers, NGINX, Kubernetes, VMs etc. |
| Filas | Ingerir webhooks para processamento assíncrono, limites de timeout do provedor, nivelamento de carga e roteamento a consumidores etc. | Google Cloud Pub/Sub, Kafka, Amazon SQS, RabbitMQ, Azure EventBus etc. |
| Runtime do consumidor | Processar webhooks, escalar horizontalmente para lidar com picos etc. | AWS Lambda, Cloudflare Workers, NGINX, Kubernetes, VMs etc. |
| Armazenamento | Persistir eventos de webhook para recuperação de erros, investigação, rate limiting e trilha de auditoria | Postgres, S3, DynamoDB, Redis etc. |
| Alertas e logging | Monitoramento e alertas, recuperação de erros | ELK stack, Datadog, New Relic, Prometheus, Grafana etc. |
| Scripts customizados | Retries de mensagens em dead letter, investigação, rate limiting etc. | |
| Desenvolvimento e testes | Testes unitários e ponta a ponta de webhooks | ngrok, Postman |
Como você deve ter percebido, dá muito trabalho configurar e manter todas essas ferramentas para ter webhooks resilientes. E, mesmo que os times de engenharia tenham feito o melhor possível com elas, essa não é a solução ideal, pelos seguintes motivos:
- O peso de manter ferramentas de fornecedores diferentes
- Nenhum workflow padronizado
- Você obtém resiliência de melhor esforço
- A qualidade da sua infraestrutura de webhooks é diretamente proporcional à experiência do seu time
- Um fornecedor pode introduzir uma mudança que quebra outras dependências
- A inércia dos times em criar ou manter documentação da infraestrutura de webhooks
- Dificuldade em integrar novos funcionários (novos membros precisam aprender um monte de ferramentas)
Essas são algumas das desvantagens dessa estratégia legada com a qual todos nos acostumamos ao longo dos anos. Mas existe algo muito melhor do que uma solução composta para gerenciar webhooks, e é isso que vamos discutir a seguir.
A solução recomendada
Ao procurar uma solução para webhooks, o foco deve ser a experiência de desenvolvimento. Você não quer que as suas melhores cabeças percam tempo fazendo um monte de ferramentas conversarem entre si e resolvendo problemas de integração quando poderiam estar focadas em questões mais próximas do cliente.
Você não precisa de várias ferramentas, precisa de apenas uma. Uma ferramenta focada em webhooks, bem documentada, mantida constantemente e confiável, que ofereça exatamente as funcionalidades necessárias para tornar os seus webhooks resilientes em produção.
Você precisa de uma infraestrutura de webhooks que fique entre o seu produtor e os seus consumidores para desacoplar e intermediar todas as interações entre as duas partes. Essa infraestrutura cuida de todos os requisitos de produção dos seus webhooks, como:
- Autenticação
- Monitoramento
- Recuperação de erros
- Alertas
- Investigação de problemas
- Coordenação de workflows para um ou vários provedores e consumidores de webhooks
- …e muito mais
Curioso para saber qual é essa ferramenta? Entra em cena a Hookdeck.
A missão da Hookdeck é simples: garantir que você nunca perca um webhook. A Hookdeck foi construída exclusivamente para lidar com webhooks e, por isso, as suas funcionalidades são feitas sob medida para garantir que os seus webhooks cumpram o seu propósito enquanto viajam de um ponto a outro.
A Hookdeck cuida de todas as responsabilidades de uma solução confiável de webhooks listadas acima e de mais algumas. Você pode trabalhar com vários provedores, rotear os seus webhooks para quantos endpoints quiser, transformar payloads antes que cheguem ao destino, ter autenticação pronta para uso, reenviar automaticamente webhooks com falha, pausar webhooks que estão falhando e desenhar um workflow que combine com o seu modo de operação.
E, como você já deve ter imaginado, a Hookdeck é minuciosamente documentada, garantindo que você tenha respostas para todas as suas dúvidas sobre webhooks e consiga integrar novos membros do time de forma rápida e fácil.
Para saber mais sobre a Hookdeck, confira a nossa documentação.
Conclusão
A simplicidade dos webhooks pode ser enganosa, deixando engenheiros e times de desenvolvimento cegos para a sua fragilidade em ambientes de produção. Entender os problemas que os webhooks enfrentam em produção e como mitigá-los ajuda a estar mais preparado para o inevitável. Embora não seja possível cobrir todos os problemas dos webhooks nesta série, esperamos que as informações aqui ajudem você a ser mais proativo ao lidar com essas questões.
Ou você pode simplesmente criar uma conta na Hookdeck hoje e nunca mais se preocupar em perder um webhook.
Infraestrutura de webhooks, gerenciada para você
A Hookdeck cuida da ingestão, entrega, observabilidade e recuperação de erros — para que você não precise.