Ingress Gateway Canônico de Webhooks & Proxy Forwarder

1. Visão Geral

O endpoint POST /api/integrations/whatsapp/webhook no web-app opera como proxy forwarder transparente de compatibilidade para o Edge Ingress Gateway nativo hospedado na VPS (https://api.connect.yzex.com.br/v1/webhooks/integrations/whatsapp).

2. Eliminação do Antipattern de AMQP Connection Churn em Serverless

Conforme deliberado na evolução arquitetural CS-20260912-001: * Problema Resolvido: A abertura de conexões AMQP diretas ao RabbitMQ a partir de funções serverless (Vercel) causava exaustão de sockets, timeouts de handshake TCP e instabilidade operacional por conexão efêmera (connection churn). * Solução Canônica: O cliente amqplib e o utilitário server/utils/amqp.ts foram integralmente removidos do web-app. * Ingress Nativo de Borda: A conexão durável e contínua com o RabbitMQ agora reside no yzex-worker-service:3001 dentro da rede privada Docker da VPS (yzex-network), exposto via Traefik v3.

3. Princípio de Zero I/O no Banco OLTP Transacional

No caminho crítico da requisição HTTP do webhook no web-app: * Nenhuma conexão ou query com o banco relacional PostgreSQL (connect) é efetuada. * O payload não disputa pools de conexão ou locks com a operação do usuário. * O proxy valida formato, limite de tamanho (10 MB) e despacha o stream bruto via HTTPS diretamente para o Edge Ingress Canônico da VPS.

4. Contrato de Resiliência e Códigos de Retorno

  1. O proxy encaminha headers de rastreamento (x-request-id, traceparent), autenticação (authorization, x-webhook-token, apikey) e contexto de provedor (x-provider, x-instance).

  2. Repassa o status HTTP retornado pela borda (200 OK, 401 Unauthorized, 413 Payload Too Large, 503 Service Unavailable).

  3. Em caso de indisponibilidade ou falha na comunicação de rede com o gateway de borda, o proxy retorna HTTP 503 Service Unavailable, instruindo o provedor WhatsApp a acionar seu mecanismo de retentativa com backoff.