O que causa downtime em webhooks e como lidar com os problemas

Toda aplicação web, incluindo as APIs que consomem webhooks, roda em um ambiente de hospedagem responsável por servir a aplicação. Downtime é o estado em que a aplicação não está disponível para atender requisições, uma condição sempre indesejada, já que pode afetar terrivelmente a experiência do usuário e, muitas vezes, causar perda de receita. Cabe, portanto, aos engenheiros da aplicação projetar o sistema para evitar ao máximo o downtime do servidor e os seus efeitos.

Neste artigo, examinamos as diferentes causas de downtime de servidor e discutimos as formas recomendadas de lidar com esses cenários.

Quais cenários causam downtime para webhooks?

Picos de tráfego

A capacidade dos ambientes de servidor depende dos recursos computacionais disponíveis para eles. Memória e espaço em disco são exemplos de recursos finitos em ambientes de servidor. Quanto mais conexões um servidor precisa abrir e mais requisições precisa processar simultaneamente, mais memória e recursos de sistema são consumidos.

Assim, se o consumidor dos seus webhooks estiver processando mais webhooks do que a capacidade do servidor suporta, o servidor vai cair. Durante esse downtime, os webhooks que tentarem chegar ao seu endpoint serão descartados com um erro 503 (Service Unavailable).

Até o servidor voltar, ele não conseguirá processar nenhum webhook, e muitos dados sensíveis podem se perder nesse período.

Para aprender a resolver picos de tráfego, confira este artigo.

Migração de servidor

Às vezes, por questões de aumento de capacidade ou por preferência, você precisa migrar a sua aplicação para um servidor diferente. Nesse período, o seu serviço passará por downtime até que a configuração no novo servidor esteja completa e o tráfego seja redirecionado com sucesso para o novo ambiente.

Esse período de downtime vai afetar os seus webhooks, porque provavelmente você não terá o luxo de pausar os webhooks nem de pedir aos seus usuários que parem de usar a aplicação durante a migração.

Correções de integridade de dados

Problemas de integridade de dados ocorrem quando o processamento inadequado de webhooks deixa os dados da sua aplicação em um estado inconsistente. Ao perceber isso, você pode precisar bloquear a escrita no banco de dados até conseguir restaurá-lo a um estado consistente.

Durante esse bloqueio, os seus webhooks não conseguirão executar operações que manipulam dados no banco e vão sofrer timeout depois de algum tempo.

Às vezes, servidores são desligados intencionalmente para corrigir problemas relacionados a comprometimento de dados e, nesse período, os webhooks serão descartados, o que pode gerar ainda mais problemas com os dados.

Downtime por atualização de servidor

O software que roda nos servidores de aplicação costuma exigir atualizações. Exceto por funcionalidades centrais que dependem de versões mais antigas, é altamente recomendável manter o software do servidor sempre atualizado.

No entanto, essa operação de atualização pode às vezes atrapalhar o funcionamento da aplicação ou exigir que ela fique fora do ar enquanto a atualização acontece. Por isso, as requisições de webhook direcionadas às suas URLs vão falhar durante a atualização.

Falha de autenticação

Por questões de segurança, os provedores de webhooks costumam exigir uma etapa de autenticação antes que a informação de um webhook possa ser consumida. Se o consumidor do webhook (ou seja, o seu servidor) não atender aos requisitos de autenticação, os webhooks serão descartados com um erro 401 (Unauthorized).

O seu servidor pode até estar no ar, mas o efeito sobre a operação dos webhooks é o mesmo de um downtime.

Como administrar cenários de downtime de webhooks para garantir confiabilidade

O principal problema do downtime do servidor é que os webhooks continuam sendo enviados ao seu endpoint, mas o servidor não consegue processá-los. Isso leva à perda de informação e, se não houver como receber os webhooks novamente, essa informação pode se perder para sempre.

A solução recomendada é ingerir e armazenar temporariamente os seus webhooks durante o período de downtime, e o componente que ajuda nisso é conhecido como fila de mensagens.

Uma fila de mensagens ajuda a desacoplar o provedor do consumidor de webhooks, porque fica entre os dois. Isso isola os provedores dos consumidores, o que torna o sistema mais robusto e tolerante a falhas, já que os provedores não dependem diretamente dos consumidores.

O fato de a disponibilidade dos consumidores não afetar os provedores de webhooks permite que você interrompa o processamento a qualquer momento. Com essa capacidade, você pode fazer manutenção, corrigir problemas, instalar atualizações e realizar deploys nos seus servidores quando quiser.

Em qualquer cenário em que o seu servidor caia, uma fila de mensagens retém todos os webhooks disparados durante o período dentro da sua fila interna. Quando o servidor volta, os webhooks são entregues para processamento a partir da fila. Por isso também é importante que o seu componente de fila inclua um sistema de retry que reenvie os webhooks depois de uma falha.

Filas de mensagens podem ser construídas com bibliotecas open source como RabbitMQ e Apache Kafka.

Como a Hookdeck ajuda

Adicionar uma fila de mensagens à sua infraestrutura de webhooks e fazer com que ela funcione de forma eficaz exige bastante experiência em desenvolvimento com filas. Usar um serviço como a Hookdeck simplifica tudo. Ela foi construída com recursos para lidar com os cenários de downtime planejado e não planejado descritos acima, permitindo que você ingira, enfileire e reenvie webhooks e, no fim, evite os efeitos das quedas de servidor.

Para um guia passo a passo de como usar a Hookdeck para resolver problemas de downtime, confira a nossa série de Problemas/Soluções.

Conclusão

Quedas de servidor podem ser inevitáveis e, durante um período fora do ar, você quer garantir que está ingerindo e enfileirando os seus webhooks para processá-los depois; essa estratégia é conhecida como processamento assíncrono. Assim, você fica tranquilo sabendo que, em caso de downtime, a sua aplicação não vai perder nenhum webhook e todas as requisições serão (em algum momento) atendidas.