Proxy para times de backend: onde entra na arquitetura

Quando um sistema começa a precisar de proxy para chamadas externas, a tentação é adicionar a configuração direto onde a chamada HTTP já existe. Funciona no começo, mas espalha uma decisão de infraestrutura por todo o código — e vira dívida técnica rápido.

Padrão recomendado: camada de integração isolada

Em vez de configurar proxy em cada client HTTP individual, centralize em um módulo de saída único — um "gateway de requisições externas" que todo código que precisa sair para a internet passa por ele.

# integracoes/http_client.py
class ClienteExterno:
    def __init__(self, proxy_config):
        self.proxies = proxy_config

    def get(self, url, **kwargs):
        return requests.get(url, proxies=self.proxies, timeout=10, **kwargs)

# uso em qualquer lugar do sistema
cliente = ClienteExterno(proxy_config=config.PROXY)
resposta = cliente.get("https://api.terceiro.com/dados")

Isso centraliza rotação, retry e troca de provedor de proxy em um único lugar — trocar de fornecedor não exige caçar cada chamada HTTP no código.

Worker isolado vs dentro do serviço principal

Para volume alto (scraping, integração de dados em lote), vale considerar um worker separado dedicado a chamadas via proxy, desacoplado do serviço principal via fila (Redis, RabbitMQ, SQS). Isso isola falha de rede externa do caminho crítico da aplicação — um proxy lento ou temporariamente indisponível não trava requisições internas do seu sistema.

Observabilidade específica

Métricas de chamada via proxy merecem tag própria (não misturar com chamadas internas): taxa de sucesso por IP/rotação, latência adicional, taxa de retry. Sem isso, um problema de proxy aparece só como "latência alta" genérica, difícil de diagnosticar.

Próximos passos

Se seu sistema já tem chamada de proxy espalhada em vários lugares, considerar migrar para um client centralizado é o refactor de maior retorno antes de escalar volume.