원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Se você já trabalhou com integração de pagamentos ou notificações em sistemas distribuídos, provavelmente está cansado de situações em que os dados são perdidos ou enviados em duplicidade devido a atrasos nas respostas de serviços externos ou quedas de rede. Como os webhooks garantem pelo menos uma entrega, se o servidor receptor não estiver devidamente preparado, isso leva à corrupção de dados. Este artigo aborda como simular cenários de falha no ambiente local e implementar lógica de defesa antes de fazer o deploy em produção.
Para validar situações reais de falha antes do deploy em produção, você precisa criar um pipeline de teste de caos no ambiente local. Ao combinar o tunelamento do ngrok com o Toxiproxy baseado em Docker, é possível reproduzir timeouts e quedas de rede do provedor externo. Construir esse ambiente pode reduzir em 2 horas o tempo gasto na análise e resposta a causas de falhas.
O procedimento para injetar falhas de rede usando o Toxiproxy é o seguinte: Primeiro, conecte a aplicação backend, o Toxiproxy e o ngrok via Docker Compose e configure as requisições que chegam na URL pública do ngrok para passarem pela porta 8666 do Toxiproxy antes de entrarem na porta 8080 da aplicação. Segundo, envie uma requisição cURL para a API de gerenciamento do Toxiproxy injetando um atraso de resposta de 25000 milissegundos para acionar as condições de timeout de serviços externos como o Stripe. Terceiro, aplique o toxic reset_peer para encerrar o socket à força e verificar a recuperação do pool de conexões e a captura de logs.
Transações duplicadas causadas pelo reenvio de webhooks provocam corrupção de dados durante o processo de aprovação de pagamentos. O cache em memória não é adequado porque não previne condições de corrida (race conditions) em um ambiente de servidores distribuídos. Para um bloqueio de duplicação confiável, você deve usar as transações de um RDBMS e restrições de unicidade como um portão de idempotência.
O procedimento de implementação para controlar requisições concorrentes no nível do banco de dados é o seguinte: Primeiro, crie uma tabela processed_webhooks e adicione uma restrição UNIQUE no identificador de evento exclusivo dentro do payload. Segundo, em um ambiente FastAPI com SQLAlchemy, use instruções de inserção atômicas (Insert) para registrar o status como "em processamento" e capture a exceção IntegrityError se ocorrer um conflito de concorrência. Terceiro, em caso de violação da restrição de unicidade, consulte o status do registro existente; se já for uma requisição processada, retorne um 200 OK sem alterar os dados para interromper o reenvio do serviço externo. A aplicação dessa estrutura evita acidentes de corrupção de dados decorrentes de requisições duplicadas.
Quando ocorrem falhas em dependências externas durante o processamento de webhooks, surgem eventos que excedem o número máximo de tentativas, os quais são isolados em uma Dead Letter Queue (Fila de Cartas Mortas). Deixar eventos com falha sem tratamento acumula inconsistências de dados, portanto, é necessário um processo em lote (batch) para reinseri-los com segurança quando o sistema se normalizar. Construir um script de recuperação manual baseado em Python pode economizar as 3 horas semanais gastas em recuperações manuais via SQL.
O procedimento de implementação do script em lote para reprocessar eventos isolados com falha é o seguinte: Primeiro, crie uma tabela dlq_webhooks para registrar o payload original, a mensagem de erro e o número de tentativas, e consulte os dados onde is_resolved seja falso. Segundo, para evitar picos de rede durante o reprocessamento, aplique um algoritmo de backoff exponencial com jitter e aguarde pelo tempo de atraso calculado. Terceiro, envie uma requisição HTTP para o endpoint interno, atualize is_resolved para verdadeiro em caso de sucesso, ou aumente o contador em caso de falha, impondo um limite máximo para bloquear loops infinitos.
Para manter a estabilidade do sistema de webhooks, é necessário um sistema de observabilidade que rastreie em tempo real a taxa de falha de recebimento e a quantidade acumulada na Dead Letter Queue. Para evitar a fadiga de acordar o engenheiro de plantão todas as noites devido a oscilações temporárias de infraestrutura, você deve estabelecer uma política de alertas estratificada com base na natureza do erro.
O procedimento de configuração de monitoramento para reduzir falsos positivos e responder apenas a falhas reais é o seguinte: Primeiro, calcule a taxa de falha de webhooks com base no número de respostas HTTP 5xx e de timeout em relação ao total de recebimentos nos últimos 10 minutos. Segundo, separe e visualize erros temporários de infraestrutura e erros de lógica de negócios no painel (dashboard). Terceiro, acione chamadas de emergência no PagerDuty apenas quando a taxa de falha exceder 15% e a Dead Letter Queue ultrapassar 100 itens, silenciando timeouts simples durante a noite para reduzir a fadiga do plantão.
