Boas práticas para colocar webhooks em produção

Você já introduziu webhooks na sua arquitetura e agora está pronto para levar tudo para um ambiente de produção. É sabido que as coisas em produção nem sempre saem como esperado, ao contrário do que acontece em desenvolvimento. Um ambiente de desenvolvimento é mais previsível e controlável do que um de produção. Algumas características do ambiente de produção são tráfego imprevisível, dados indesejados, tipos de dados errados, indisponibilidade do provedor de hospedagem e ataques de segurança, entre muitas outras.

Este artigo apresenta alguns passos recomendados que você deve considerar antes de levar os seus webhooks para produção.

Configuração dos webhooks

Troubleshooting e testes locais de webhooks

O primeiro passo é garantir que você testou os seus webhooks adequadamente no ambiente de desenvolvimento.

Requisições de webhook disparadas por aplicações que você não controla (o que é o caso na maior parte das vezes) provavelmente não serão disparadas de novo. Ou seja, se você não consumir corretamente o webhook quando ele for disparado, pode não ter uma segunda chance e o seu sistema pode sofrer perdas.

Testando, você pode disparar requisições de webhook fictícias e depurar erros no seu código durante o processamento da requisição. Quando tudo estiver certo, você pode seguir para o deploy dos webhooks em produção.

Um dos pontos de dor do desenvolvimento local com webhooks é que você precisa de um endpoint seguro que não está disponível para servidores rodando localmente. Além disso, o endpoint precisa ser publicamente acessível para que os provedores de webhook consigam alcançá-lo.

Proteja a URL do seu webhook

Requisições de webhook são requisições HTTP comuns, o que as torna suscetíveis às mesmas vulnerabilidades de segurança típicas de operações HTTP. Atacantes podem facilmente se aproveitar de um sistema comprometido para injetar dados corrompidos nos seus webhooks e causar efeitos indesejados nos seus servidores.

Abaixo está o resumo das verificações de segurança que você deve fazer:

• Criptografe as requisições de webhook usando sempre um certificado SSL nas URLs dos seus webhooks.
• Verifique de onde os seus webhooks estão vindo, para garantir que têm origem na fonte correta.
• Provedores de webhook também devem verificar os consumidores do webhook usando estratégias como segredos de API ou tokens de autenticação.
• Verifique se o payload não contém dados corrompidos.
• Previna ataques de replay verificando o timestamp da mensagem.

Esta não é uma lista exaustiva e recomendamos que você tome mais precauções para as vulnerabilidades que identificar além dessa lista.

Escalabilidade de webhooks

Processamento assíncrono com filas de webhooks

Outra configuração recomendada quando você precisa trabalhar com webhooks em produção é uma fila de mensagens.

É muito comum atingir limites de capacidade ao tentar processar todas as requisições de webhook imediatamente. Uma vez que a capacidade do servidor é excedida, ele para de responder e você não consegue mais processar webhooks. Escrevemos uma introdução ao processamento assíncrono caso você queira se aprofundar.

Uma fila de mensagens ajuda a evitar essa situação fazendo buffer dos seus webhooks e entregando-os ao seu servidor a uma taxa que não o derrube. A fila de mensagens fica entre o provedor de webhook e o seu servidor e atua como um proxy para as requisições.

Você pode montar filas de mensagens com tecnologias open source como RabbitMQ e Apache Kafka. No entanto, filas de mensagens adicionam uma camada extra à sua arquitetura e, em certos níveis de tráfego, também precisam ser escaladas para evitar indisponibilidade. Elas também exigem que você entenda bem o funcionamento interno para usá-las corretamente.

Para saber mais, leia Introdução a filas de mensagens e Filas de mensagens em profundidade.

Rate limiting de webhooks para evitar problemas de escala

Todo servidor é limitado pelos seus recursos, e esses recursos determinam o volume de tráfego web que ele consegue suportar. O rate limiting permite limitar o número de requisições que chegam ao seu servidor à taxa que ele consegue processar em cada momento. Se o seu servidor só consegue processar cem requisições por segundo, considere definir um rate limit de 80 a 90 requisições/segundo (isso mesmo, não 100: você precisa deixar alguma folga para garantir estabilidade).

Você também pode limitar o total de requisições processadas em um determinado período. Por exemplo, é possível definir um limite rígido por hora que garanta que o seu servidor processe no máximo 2000 requisições a cada hora.

O rate limiting é mais útil quando você ainda não está pronto para escalar os seus servidores e pode tolerar um pequeno atraso enquanto as requisições em buffer esperam as ativas terminarem de ser processadas.

Montar um sistema de rate limiting pode ser feito com timers e cron jobs, mas normalmente não é tão simples assim. A lógica para mantê-lo estável e eficiente às vezes é complexa.

Escalabilidade horizontal

Quando o seu tráfego de webhooks chegar ao ponto em que você precisa processar dezenas de milhares de webhooks por dia, é hora de considerar escalar os seus servidores horizontalmente.

A escalabilidade horizontal permite distribuir o tráfego entre várias cópias do seu servidor. Um load balancer é posicionado entre o provedor de webhook e o seu conjunto de servidores. O load balancer usa diferentes tipos de algoritmos (round-robin, least connection, weighted round-robin etc.) para distribuir de forma eficaz o tráfego de webhooks entre mais de uma cópia do seu servidor.

Isso reduz o peso de ter apenas um servidor processando todas as requisições. A escalabilidade horizontal também pode ser combinada com filas de mensagens, com o load balancer distribuindo tráfego entre múltiplos pares fila-servidor.

Recuperação de erros em webhooks

Logging de webhooks para trilhas de auditoria

Uma configuração altamente recomendada para os seus webhooks em produção é o logging. Você precisa conseguir rastrear as requisições de webhook e saber o status delas o tempo todo, especialmente quando falham.

Quando webhooks falham, informações sobre a falha ajudam a depurar e corrigir o problema. Você pode fazer logging com diferentes estratégias, desde escrever logs em arquivos simples até usar um serviço de logging padrão de mercado.

Retries de webhooks

Às vezes, por mais precauções que você tome, os webhooks ainda falham. O importante é ter uma forma de se recuperar da falha, o que se consegue fazendo novas tentativas das requisições de webhook.

Alguns provedores de webhook fazem isso automaticamente para você, mas não é recomendável deixar essa responsabilidade com eles. Você deve ter o controle do seu sistema de retry.

A forma como a maioria das pessoas de engenharia resolve isso é salvando os eventos no banco de dados assim que são recebidos, antes de serem processados. Assim, se o processamento falhar, o evento persistido no banco pode ser tentado de novo até ser processado com sucesso.

O seu sistema de retry também precisa garantir que os eventos sejam removidos do armazenamento assim que forem processados com sucesso. Você pode ir além adicionando configurações de número máximo de retries, alertas quando esse número for excedido para investigar a situação e muitos outros recursos que tornam o sistema de retry mais flexível e confiável.

Como a Hookdeck pode ajudar

Colocar webhooks em produção com todas as boas práticas deste guia (retries, backpressure, observabilidade, idempotência, verificação de assinatura) significa construir um pedaço nada trivial de infraestrutura que tem muito pouco a ver com o seu produto de verdade. O que começa como um único handler de endpoint vira queues, workers de retry, ferramentas de observabilidade, verificação de assinatura e runbooks operacionais antes mesmo de você entregar a funcionalidade que os webhooks deveriam sustentar.

O Event Gateway da Hookdeck é uma infraestrutura de webhooks gerenciada que cuida de ingestão, entrega com backpressure, retries, observabilidade e verificação de assinatura por padrão. Ele fica entre os seus provedores de webhook e a sua aplicação como uma fila gerenciada — absorvendo picos de tráfego, fazendo buffer das entregas e dando a você o rastro completo de cada evento sem precisar operar nada disso. Comece a usar a Hookdeck e pule os meses de encanamento que uma infraestrutura de webhooks em produção normalmente exige.

Conclusão

Tudo se torna crítico quando você sai de um ambiente de desenvolvimento para um de produção. Isso acontece porque a tolerância a falhas em produção é muito baixa quando comparada a ambientes de desenvolvimento.

Seguindo as recomendações deste artigo, você pode dormir tranquilo sabendo que os seus webhooks vão se comportar bem em produção. Para um detalhamento mais aprofundado sobre sobreviver a ambientes de produção, veja este artigo.