Recuperação de erros

Erros são inevitáveis quando se trabalha com webhooks. É por isso que é essencial construir resiliência nos webhooks tornando-os tolerantes a falhas. Tolerância a falhas para webhooks é a capacidade de voltar ao estado desejado na aplicação consumidora apesar da ocorrência de erros. Para saber mais sobre como webhooks funcionam, confira o nosso artigo sobre o que são webhooks e como eles funcionam.

Neste artigo, vou passar pelos problemas mais comuns de recuperação de erros que você pode encontrar ao trabalhar com webhooks e explicar como resolvê-los com o Hookdeck. Cada problema abordado inclui uma pequena seção de discussão.

O que são erros de webhook?

Um erro de webhook é qualquer situação que impeça um webhook de cumprir o propósito pretendido na aplicação de destino. Erros de webhook podem vir do produtor, do consumidor, do link de rede entre eles e/ou de qualquer componente intermediário do processo de comunicação.

Alguns exemplos de erros de webhook:

• Erros de rede: falhas de rede entre produtor e consumidor, timeouts de requisição etc.
• Erros de protocolo: erros de autenticação, requisições malformadas, formatos inválidos, clientes não autorizados, chaves de acesso expiradas etc. Tipicamente erros 4xx.
• Erros do consumidor: erros de código (bugs), timeouts de banco de dados etc. Tipicamente erros 5xx.

Recuperando-se de erros de webhook (resiliência de webhooks)

Vamos supor que você esteja perdendo webhooks por causa de um erro. Como pausar o link de comunicação entre produtores e consumidores para garantir que você não continue perdendo webhooks?

E como recuperar e fazer retry de todos os webhooks que falharam depois de aplicar uma correção? E se você quiser testar apenas um webhook com falha para confirmar a correção e só depois testar os demais?

O processo de recuperação de erros de webhook pode ser dividido em 3 estágios, que vamos discutir brevemente.

1) Rastreamento

Primeiro vem o estágio de rastreamento. Ele envolve monitorar os seus webhooks para capturar erros e disparar alertas. Ferramentas como o Bugsnag foram feitas especialmente para isso, enquanto ferramentas de monitoramento padrão como o Datadog podem ser configuradas para observar e alertar sobre erros.

2) Debug

Em seguida vem o estágio de debug. Ele envolve investigar o erro para determinar a causa raiz. Você quer uma ferramenta que forneça dados suficientes para descobrir o que causou o erro, mas não tanta informação a ponto de virar ruído e sobrecarregar.

3) Recuperação

E então temos a recuperação que, por mais óbvia que pareça, realmente não tem nenhuma ferramenta padrão quando o assunto é webhooks. Recuperação é a capacidade de devolver a sua aplicação ao estado pretendido depois que uma falha acontece.

Na próxima seção, vamos ver como o Hookdeck ajuda a resolver esses (e muitos outros) problemas de recuperação de erros.

Como o Hookdeck te ajuda a se recuperar de erros

Você está perdendo webhooks porque o seu servidor caiu durante um pico

Problema

Você precisa aplicar rate limit nos webhooks de entrada.

Solução

O Hookdeck permite definir um rate limit por destination, limitando o teto de quantos webhooks o seu destino pode receber em um período de tempo.

Picos repentinos de tráfego podem fazer um servidor exceder o próprio throughput. Quando um servidor excede o throughput e os recursos disponíveis para conexões de rede e processamento de requisições se esgotam, o servidor cai.

Para resolver esse problema, você precisa controlar a taxa em que os provedores enviam webhooks para os seus servidores. Isso é feito adicionando um componente de rate limiting entre os seus provedores e os seus consumidores. Assim, você ajusta a taxa de requisições de webhook para abaixo do throughput do servidor e evita quedas.

Você precisa aplicar rate limit manualmente ao reconciliar uma correção

Problema

Você precisa configurar parâmetros de rate limiting para troubleshooting.

Solução

Os controles de rate limiting do Hookdeck permitem configurar manualmente quantos webhooks você quer receber por segundo, por minuto ou por hora. Você também pode definir o intervalo de tempo entre cada webhook enviado.

Ao aplicar uma correção, você precisa recriar o problema para ver se a correção funcionou. Com webhooks, isso envolve simular a taxa em que as requisições foram recebidas até o erro acontecer.

Para conseguir isso, você precisa de um componente de rate limiting configurável manualmente. Esses botões de rate limiting permitem definir a taxa de webhooks recebidos por segundo exatamente no valor que você quer para as suas atividades de troubleshooting.

Você está perdendo webhooks porque o seu servidor caiu

Problema

Você precisa pausar os seus webhooks.

Solução

As connections do Hookdeck têm um recurso de Pause que pode ser usado para interromper temporariamente a entrega dos seus webhooks de uma source para o seu servidor de destino. Isso permite evitar a perda de webhooks enquanto a indisponibilidade do servidor persiste.

Quando um servidor de destino de webhooks está indisponível, os webhooks que chegam nele são descartados automaticamente. Isso causa perda de informação e deixa a aplicação em um estado inconsistente.

Para evitar perder webhooks, você precisa parar de enviá-los ao seu servidor e mantê-los em armazenamento temporário até o servidor voltar. Isso pode ser feito usando uma fila de mensagens para guardar os dados dos webhooks. Você também precisa garantir que o período de persistência dos dados definido na fila seja suficiente para cobrir a duração da indisponibilidade.

Você está perdendo webhooks porque o seu servidor está passando por downtime

Problema

Você precisa pausar a entrega de webhooks enquanto o seu servidor está fora e retomar quando ele voltar.

Solução

Use Pause na entrega dos seus webhooks para o servidor de destino. Use Unpause quando for seguro receber webhooks de novo.

Downtime de servidor costuma ser necessário para migrar dados, aplicar atualizações ou fazer upgrade do servidor. Qualquer webhook enviado ao servidor nesse período é descartado automaticamente.

Para evitar perder webhooks, você precisa parar de enviá-los ao seu servidor e mantê-los em armazenamento temporário até o servidor voltar. Isso pode ser feito usando uma fila de mensagens para guardar os dados dos webhooks. Você também precisa garantir que o tempo de persistência dos dados definido na fila seja suficiente para cobrir o período de downtime.

Você está perdendo webhooks porque atingiu o rate limit da API

Problema

Você precisa controlar o ritmo da entrega.

Solução

Se as requisições de webhook de um provedor para um consumidor excedem a taxa que o servidor consumidor consegue suportar, os webhooks seguintes serão descartados. Os webhooks perdidos nesse período causam inconsistências de dados na aplicação consumidora.

Para resolver isso, você precisa reduzir a taxa em que as requisições de webhook são enviadas à sua aplicação. Isso é feito adicionando um componente de rate limiting entre produtor e consumidor para ajustar o ritmo da entrega a uma frequência que não exceda o limite da API consumidora.

Você está perdendo webhooks porque o seu servidor caiu depois de um pico

Problema

Você precisa fazer retry de todos os webhooks que falharam por causa do pico.

Solução

Busque os Events que retornaram o código HTTP 503 usando os Filters. Use o recurso de Bulk Retry para recuperar os webhooks perdidos.

Quando picos derrubam o seu servidor, vários webhooks já terão falhado antes de você achar uma solução. Depois de aplicar uma correção, você precisa encontrar e fazer retry de todos os webhooks que falharam durante a indisponibilidade.

A solução recomendada é persistir proativamente os seus webhooks em um repositório de dados e só descartá-los quando tiver certeza de que foram reconciliados com o seu servidor. Assim, quando houver downtime, você não perde a informação dos webhooks. Quando o servidor voltar, você pode fazer retry dos webhooks que falharam. Para mais sobre lidar com cenários de indisponibilidade, veja o que causa downtime de webhooks e como lidar com os problemas.

Você está perdendo webhooks porque o seu servidor retorna erros depois de um release ruim

Problema

Você precisa identificar os webhooks perdidos e reenviá-los.

Solução

As Issues do Hookdeck categorizam as falhas por connection e código de status. Você pode então navegar pela issue para identificar todos os eventos impactados. Uma vez corrigido o problema, você pode fazer retry de todos os webhooks com o Bulk Retry e marcar a issue como resolvida.

Quando webhooks falham por erros de servidor, você precisa de uma trilha de auditoria das transações de webhook para descobrir por que eles estão falhando.

A forma padrão de rastrear as atividades de um webhook é registrando logs em diferentes pontos da jornada da origem até o destino. Como os erros vêm do seu servidor, os logs dele são a fonte da verdade para determinar o que deu errado com os seus webhooks.

Uma vez detectado o bug e aplicada a correção, você precisa fazer retry de todos os webhooks que falharam por causa dele. Uma das formas de conseguir isso é armazenar as requisições de webhook com falha em dead letter queues (de um message broker) e recuperá-las para fazer retry assim que o problema for resolvido.

Como o Hookdeck ajuda

Recuperar-se de falhas em webhooks é mais do que registrar o erro em log. É saber o que falhou, por que falhou, reenviar os eventos afetados depois de corrigir a causa raiz e fazer isso sem perder dados nem criar duplicatas. Construir isso do zero significa implementar rastreamento de falhas, tratamento de dead letter, ferramentas de replay manual e deduplicação, e manter tudo isso ao lado do código do seu produto de verdade.

O Event Gateway do Hookdeck é infraestrutura gerenciada para receber e entregar webhooks de forma confiável. Ele faz retry automático das entregas com falha com estratégias de backoff configuráveis, agrupa falhas relacionadas em Issues para você ver as causas raiz e fazer retry em massa dos eventos afetados com um clique, e oferece deduplicação nativa para que eventos reenviados nunca produzam efeitos colaterais duplicados. Cada entrega é rastreada ponta a ponta, com payload, headers e dados de resposta completos.