Por que confiar nos provedores de webhooks não é a resposta

No artigo anterior, discutimos como a delegação de funções comuns de aplicação, como pagamentos, por meio da integração com provedores terceiros levou ao aumento do uso de webhooks nas aplicações modernas.

Também destacamos a necessidade de ter uma infraestrutura de webhooks resiliente, com recursos de observabilidade, para garantir estabilidade operacional.

Neste artigo, vou explicar por que, apesar de termos enfatizado a necessidade de resiliência e observabilidade, não é recomendável depender do seu provedor de webhooks para oferecer esses recursos.

O papel dos provedores de webhooks nas suas integrações

Quando se trata da integração com serviços de terceiros, como e-commerce ou pagamentos, as aplicações SaaS são os provedores de webhooks. Elas usam webhooks para notificar e transferir informações sobre um evento para a sua aplicação.

Um fato importante para entender quanta responsabilidade você precisa assumir pelos seus webhooks é que os provedores não têm ideia de qual webhook é crucial para você, então eles otimizam o envio de todos os webhooks o mais rápido possível.

Eles costumam seguir um estilo de comunicação fire-and-forget, deixando que você colete e processe os webhooks de acordo com a importância de cada um. Esse comportamento permite que os provedores otimizem velocidade e entrega. Ao mesmo tempo, você assume a responsabilidade pela priorização, pela persistência temporária para processamento assíncrono, pelos retries e por outras atividades personalizadas nos seus webhooks.

Como só você sabe o quanto um webhook é importante para a sua operação, está nas suas mãos garantir a captura dos que interessam, porque o trabalho do provedor é fazer com que todos os eventos saiam pela porta.

Na próxima seção, veremos quanta responsabilidade os provedores de webhooks assumem em casos de falha. Isso vai nos ajudar a entender o tipo de problema que a nossa infraestrutura de webhooks deve resolver.

Quanta responsabilidade o seu provedor de webhooks assume quando:

Os seus servidores estão sobrecarregados

Quando os seus servidores estão sobrecarregados, a latência aumenta no tempo de processamento de cada webhook. Essa situação pode fazer com que webhooks sejam descartados caso ultrapassem o limite de tempo de resposta definido pelo provedor. Além disso, se a sobrecarga persistir, o seu servidor vai acabar caindo.

Os provedores continuam otimizando a entrega e querem garantir que você receba os webhooks o mais rápido possível; por isso, eles vão continuar enviando mesmo com o seu servidor sobrecarregado. Alguns provedores reduzem o ritmo de entrega ao notar tempos de resposta altos; ainda assim, o objetivo principal continua sendo entregar os webhooks a você o quanto antes.

Você precisa fazer uma migração sem interrupções

Ao migrar, os seus servidores precisarão ficar offline durante o período de migração. Isso fará com que você perca todos os webhooks nesse intervalo. Como os provedores não conseguem determinar a importância de cada webhook, eles vão continuar otimizando a entrega durante esse período.

Os seus webhooks estão sofrendo timeout

Webhooks que sofrem timeout são reenviados algumas vezes (nos provedores que oferecem retries automáticos) e depois descartados, caso continuem estourando o tempo ou falhando de imediato. Como vimos no artigo anterior, webhooks descartados levam à perda de informações de eventos sobre os quais você precisa agir, o que pode impactar negativamente o seu negócio.

Enquanto alguns provedores oferecem retries automáticos ou manuais (ou ambos) para webhooks descartados, outros seguem otimizando a entrega e enviando webhooks continuamente para os seus servidores.

Os seus servidores caem

Quando o seu servidor cai, você não consegue atender mais nenhum webhook até que ele volte. Durante a indisponibilidade, todos os webhooks enviados para a sua URL vão acabar encontrando um erro de servidor e serão descartados.

Como a responsabilidade central dos provedores é otimizar a entrega para que você não perca nenhum webhook, você vai continuar recebendo webhooks durante a queda, e agora é sua responsabilidade capturá-los para processá-los quando o servidor voltar.

Você precisa reenviar um webhook que falhou

Quando um webhook falha, ele precisa ser capturado e reenviado para reconciliar a informação do evento com a sua aplicação. Não reprocessar eventos que falharam pode causar problemas de integridade de dados na sua aplicação e levar à perda de negócios.

Ainda que alguns provedores reenviem automaticamente um webhook que falhou algumas vezes após o descarte, a responsabilidade central do provedor continua sendo otimizar a entrega rápida dos webhooks ao destino.

Por exemplo, o Twilio só reenvia webhooks que falharam até 5 vezes, o que pode ou não ser suficiente para que o problema seja resolvido.

A Stripe oferece uma forma de reenviar manualmente um webhook que falhou. Embora seja uma ferramenta prática, ela não escala para reenviar um grande lote de webhooks com falha. Imagine precisar reprocessar mil webhooks que falharam por causa de uma queda de servidor; entrar no dashboard do provedor para reenviá-los um a um é inviável.

Você ainda precisa de uma infraestrutura de webhooks capaz de reenviar um grande volume de requisições com falha sem ter que fazer isso uma a uma.

Para mais informações sobre os recursos disponíveis nos diferentes provedores de webhooks, confira os nossos guias de plataformas de webhooks.

Você vai precisar de resiliência e observabilidade

Os cenários descritos acima não são uma lista exaustiva, mas estão entre os problemas mais comuns que você vai enfrentar ao rodar webhooks em produção. Para saber mais sobre problemas com webhooks, confira a nossa série de artigos e conheça as questões mais comuns e as soluções recomendadas.

Os cenários acima apontam na direção dos problemas mais importantes que você deveria estar tentando resolver: resiliência e observabilidade.

Então, o que são resiliência e observabilidade no contexto de webhooks?

Resiliência em webhooks

Resiliência é a medida da robustez da sua infraestrutura de webhooks diante de pressões de carga e falhas. As funções cobertas por resiliência incluem:

• Tolerância a falhas
• Recuperação de erros/falhas
• Escalabilidade
• Auto-recuperação
• Configurabilidade

Observabilidade das atividades de webhooks

A observabilidade complementa a resiliência ao dar visibilidade sobre as atividades dos seus webhooks e ajudar você a identificar padrões ao longo do tempo, para tomar decisões informadas na hora de fortalecer o sistema contra falhas e pressões de carga.

As atividades cobertas por observabilidade incluem:

• Monitoramento
• Alertas
• Automação de atividades personalizadas de recuperação de falhas e autoescalonamento

Ao desenvolver uma infraestrutura de webhooks resiliente com recursos de observabilidade, você reduz a taxa de erro dos webhooks, resolve automaticamente falhas comuns, depura mais rápido e mantém um tempo de resposta eficiente na correção de problemas críticos. Para orientações sobre monitoramento, veja o que monitorar em uma infraestrutura de webhooks.

Um dos provedores de webhooks que detalha claramente as responsabilidades do consumidor é a Shopify, na sua página de boas práticas de webhooks. Ali eles explicam que é responsabilidade do consumidor do webhook:

• Responder rapidamente para evitar timeouts
• Acompanhar falhas com ferramentas de observabilidade, como as métricas no dashboard da Shopify
• Recuperar webhooks com falha a partir de armazenamentos de persistência temporária
• Evitar duplicidades adicionando identificadores únicos e tornando os seus endpoints idempotentes
• Usar timestamps para evitar webhooks falsificados
• Implementar rotinas de reconciliação para rebuscar e reenviar webhooks
• Construir uma infraestrutura de webhooks escalável e confiável com um sistema de mensageria testado em produção

A arquitetura orientada a eventos resolve essa necessidade

Felizmente, já existe um padrão arquitetural consolidado ao longo dos anos que se encaixa perfeitamente como solução para os problemas que vêm com os webhooks: a arquitetura orientada a eventos.

A arquitetura orientada a eventos é um padrão arquitetural distribuído e assíncrono muito popular para construir aplicações altamente escaláveis e performáticas. Em um dos nossos artigos anteriores, já falamos da importância de processar os seus webhooks de forma assíncrona (mais sobre isso no próximo artigo), e a arquitetura orientada a eventos foi projetada para lidar com esse estilo de processamento.

O padrão brilha quando o assunto é lidar com componentes de processamento de eventos desacoplados, como acontece no canal de comunicação do provedor de webhooks para o consumidor de webhooks. Uma das suas grandes vantagens é poder ser usado como estilo arquitetural autônomo ou embutido em uma arquitetura existente. Nos próximos artigos, vamos aprofundar como os atributos dessa arquitetura ajudam a resolver os problemas do dia a dia com webhooks.

Conclusão

Neste artigo, expliquei que não podemos depender dos provedores de webhooks para sempre entregar os nossos webhooks de forma confiável nem para nos ajudar a nos recuperar de falhas.

Um sistema resiliente com recursos de observabilidade embutidos é o caminho; felizmente, o estilo de arquitetura orientada a eventos existe justamente para isso.

O próximo artigo mergulha nas boas práticas de processamento de webhooks e em como o estilo assíncrono da arquitetura orientada a eventos se encaixa.

Bons códigos!