Quais são os custos de gerenciar webhooks e qual é uma solução escalável?

Webhooks se tornaram uma das formas mais populares de aplicações distribuídas se comunicarem. Aplicações SaaS oferecem webhooks para integração com aplicações sob medida. Um dos fatores que tornam os webhooks populares é a facilidade de uso; no entanto, há um custo escondido nisso. Para entender os fundamentos, veja o que são webhooks e como eles funcionam.

Nesta série, vamos ampliar o zoom sobre webhooks e seus custos operacionais em ambiente de produção. Começaremos explorando possíveis falhas, analisaremos o impacto delas e discutiremos as frustrações envolvidas em reconciliar webhooks que falharam. Depois veremos as opções de solução, calcularemos o custo de manter cada uma e proporemos uma solução melhor e mais escalável.

Ao final desta série, você terá um entendimento completo dos problemas enfrentados por times que usam webhooks, de como medir o risco e, mais importante, de como usar o Hookdeck para lidar com webhooks de forma confiável, escalável e sustentável, com uma experiência de desenvolvimento melhor.

Como os webhooks funcionam

Webhooks são um canal de comunicação de mão única entre uma fonte de eventos e um consumidor de eventos. Quando um evento ocorre na aplicação de origem (o produtor do webhook), ela dispara um webhook na forma de uma requisição HTTP para um endpoint de API na aplicação consumidora.

Essa requisição HTTP sinaliza a ocorrência do evento e transfere informações sobre ele para o consumidor, quando necessário.

Essa comunicação permite que a aplicação receptora tome uma ação com base no evento que ocorreu no produtor do webhook. Essa ação vai desde um simples registro de dados até a orquestração de uma série de tarefas a serem cumpridas em função do evento.

Para saber mais sobre como os webhooks funcionam, você pode começar pelo artigo "O que são webhooks e como eles funcionam".

Os diferentes estágios do ciclo de vida de um webhook perdido

O problema

Os problemas aparecem quando um webhook falha. Essas falhas podem ocorrer no momento do disparo, por exemplo quando o produtor não disparou o webhook. Outros problemas incluem falhas de rede enquanto o webhook está em trânsito (falhas de rede, timeout do servidor, limite de timeout do produtor atingido, etc.) e problemas de processamento (erros de servidor por releases ruins ou com bugs, esgotamento de memória, etc.).

Esses problemas quebram o pipeline de comunicação e levam a inconsistências no estado da aplicação receptora.

O impacto

Embora o impacto de uma falha de webhook tenha sido resumido acima como "inconsistência no estado da aplicação receptora", o resultado para o cliente tem consequências bem mais concretas.

Uma inconsistência no estado da aplicação significa falta de integridade dos dados, o que na vida real significa que o trabalho de um cliente foi comprometido.

Assim, um webhook que falhou pode ser o motivo de clientes não receberem os produtos que compraram, não terem a carteira digital creditada ou não receberem os ingressos de um show.

Esses impactos geram frustração nos clientes e podem destruir a credibilidade de um negócio.

Fluxo de remediação pela equipe de desenvolvimento

Então, o que fazemos quando um webhook falha? Nós corrigimos. É assim que corrigir uma única falha de webhook se parece:

• Você encontra o webhook que falhou ou está faltando
• Identifica o problema
• Corrige o problema
• Resolve a situação reconciliando o webhook que falhou ou está faltando

Fácil, certo? Não exatamente.

A frustração vem de repetir esse processo para vários webhooks que falharam. Essa rotina trabalhosa pode drenar a motivação do seu time de desenvolvimento e desperdiçar horas que poderiam ser dedicadas a aspectos mais essenciais do seu negócio.

Saiba mais sobre o problema dos webhooks perdidos no artigo "Por que webhooks são difíceis de gerenciar em produção".

O destino está (quase todo) fora das suas mãos

Falhas podem vir de qualquer entidade envolvida no pipeline de comunicação por webhooks. No entanto, apenas algumas dessas entidades estão sob o seu controle. Enquanto você controla totalmente a sua aplicação de destino, o produtor e a camada de rede provavelmente estarão fora do seu controle.

Isso acontece porque, na maioria dos casos de uso, o produtor do webhook é uma aplicação SaaS de terceiros como Shopify ou Stripe. Além disso, é o produtor que dita como a transação HTTP será conduzida pela rede.

Essa situação torna mais difícil gerenciar falhas relacionadas a timeouts de requisição, políticas de retry, formatos de dados, etc.

Além disso, com mais sucesso vêm mais webhooks e, portanto, um potencial maior de falhas. À medida que o seu negócio cresce, você começa a enfrentar problemas de escala, e um volume maior de webhooks intensifica a pressão sobre a sua infraestrutura. Se a sua infraestrutura não estiver preparada para acompanhar essa expansão, ela vai ceder e cair sob a carga.

Pela natureza baseada em eventos dos webhooks, a infraestrutura precisará escalar aos padrões de uma arquitetura orientada a eventos. Assim, o time que enfrenta essa situação vai precisar de um bom entendimento de arquiteturas orientadas a eventos.

Para entender melhor a dimensão dos problemas com webhooks, leia o artigo "Como uma abordagem assíncrona para gerenciar webhooks mitiga preocupações de escalabilidade".

A "caixa de Pandora" das soluções para webhooks

A seção anterior apontou a necessidade de conhecer arquiteturas orientadas a eventos para enfrentar os problemas que webhooks encontram em produção. Então vamos falar de soluções. Vamos supor que o time tenha um bom entendimento de arquiteturas baseadas em eventos.

Para embutir resiliência nos nossos webhooks, veja o que a stack de solução padrão para uma infraestrutura orientada a eventos exigiria:

Talvez seja só impressão minha, mas a tabela acima dá a sensação de que abrimos sem querer uma caixa de Pandora ao buscar uma solução para os nossos webhooks. Ter que lidar com tanta ferramenta grita problemas de manutenção. Além disso, dominar essas ferramentas e costurá-las de forma eficaz tem uma curva de aprendizado íngreme. Esse tipo de composição de ferramentas remendadas pode levar a uma usabilidade ruim.

Para uma visão completa de como é uma solução padrão de infraestrutura de webhooks e do custo de construí-la, confira o artigo "Por que consertar webhooks pode ser mais difícil do que você imaginava".

O que fazer?

Ao lidar com problemas de webhooks, você pode rotineiramente investigar e corrigir cada problema que aparecer, ou construir uma solução padrão que processe seus webhooks de forma assíncrona e tolerante a falhas.

Esta seção analisa duas abordagens para entender melhor o custo.

Morte por mil cortes

Você pode conviver com o problema e otimizar os seus fluxos de trabalho para percorrer com eficiência os passos rotineiros descritos acima a cada problema de webhook. No entanto, é bom ter em mente que você vai enfrentar o seguinte:

• Um monte de tempo desperdiçado investigando problemas
• Problemas operacionais rotineiros com webhooks perdidos
• Ter que gerenciar cada problema relatado pelos usuários finais
• Vasculhar logs para diagnosticar cada problema
• Montar ambientes de teste e depuração com uma infinidade de ferramentas de desenvolvimento (ngrok, Postman, scripts de ambiente de dev)
• Ter que fazer replay caso a caso na plataforma do provedor

Reinventar a roda

A opção de construir a solução padrão também está descrita na tabela da seção anterior. Essa solução considera todas as partes móveis de uma arquitetura orientada a eventos e é feita sob medida para atender a todos os seus requisitos.

Você pode ficar confiante de que os seus webhooks serão tratados de forma confiável, apesar dos custos de manutenção. No entanto, assim como na abordagem anterior, há algumas coisas a lembrar ao escolher esta opção:

• 2 a 6 meses de implementação e testes
• Exige monitoramento e manutenção constantes (talvez você precise atualizar versões de software todo ano)
• Escrita de ferramentas e scripts customizados para novas funcionalidades
• O problema recorrente da escala
• Uma curva de aprendizado íngreme e perda de conhecimento quando quem construiu a solução sai da empresa

A escolha da estratégia depende de vários fatores relacionados ao seu caso de uso e à sua situação com webhooks. Para mais informações sobre o que considerar ao escolher uma estratégia, confira o artigo "Como escolher uma estratégia para gerenciar webhooks".

Por que não usar o Hookdeck?

O Hookdeck é uma infraestrutura de webhooks que ajuda você a receber webhooks de forma confiável, mesmo após quedas de servidor. Com ele vem um conjunto de funcionalidades como retry de webhooks (manual, automático e em massa), alertas, entrega com throttling, pausa de entrega e um dashboard intuitivo que dá a você e ao seu time visibilidade total sobre a atividade dos seus webhooks.

Com o Hookdeck, você pode parar de se preocupar com a confiabilidade dos seus webhooks e focar mais em construir o seu produto. Saiba mais sobre como o Hookdeck garante resiliência no tratamento de webhooks neste artigo.

Você pode começar a usar o Hookdeck hoje gratuitamente.

Conclusão

Este artigo apresenta o custo de usar webhooks em produção e o que você precisa considerar como time em busca de uma solução. Os próximos artigos desta série vão expandir cada seção deste texto para dar todos os detalhes que ajudarão você a escolher a estratégia certa para escalar e rodar seus webhooks de forma confiável.

Comece pelo primeiro artigo da série: "Por que webhooks são difíceis de gerenciar em produção".