Construindo Infraestrutura de Monitoramento de Preços em Tempo Real

Construir uma infraestrutura de monitoramento de preços em tempo real é um desafio técnico que vai muito além de fazer requisições HTTP esporádicas. Equipes de e-commerce, resellers de ingressos e plataformas de comparação de preços precisam coletar dados de dezenas ou centenas de sites simultaneamente, lidando com rate limits, CAPTCHAs, bloqueios geográficos e mudanças frequentes no DOM das páginas-alvo. Sem uma arquitetura sólida e proxies confiáveis, o pipeline quebra em horas, não em dias.

Este guia mostra como montar essa infraestrutura do zero, com foco em implementação prática usando o ProxyHat como camada de rotação de IPs. Vamos cobrir arquitetura, escolha de tipo de proxy, código funcional e armadilhas comuns.

Por que o monitoramento de preços em tempo real é difícil

Sites de e-commerce modernos não foram projetados para serem raspados. Eles usam CDNs como Cloudflare e Akamai, que aplicam heurísticas de detecção de bots baseadas em padrões de tráfego, fingerprinting de TLS e comportamento de navegação. Quando você faz 500 requisições por minuto a partir de um único IP, o WAF detecta e bloqueia em segundos.

O problema se agrava porque preços mudam constantemente. Algumas plataformas como Amazon atualizam preços milhões de vezes por dia, conforme documentado em políticas de precificação dinâmica. Para capturar essas mudanças, você precisa de coleta frequente e distribuída — exatamente o tipo de comportamento que os sistemas anti-bot tentam impedir.

Além disso, muitos sites exibem preços diferentes conforme a localização geográfica do visitante. Um produto pode custar $49 nos EUA e €62 na Alemanha, com impostos e promoções regionais aplicados. Sem IPs na localização correta, os dados coletados são imprecisos ou incompletos.

Componentes de uma arquitetura de price monitoring

Uma infraestrutura de monitoramento de preços em tempo real típica tem quatro camadas:

• Orquestrador: define quais URLs visitar, com que frequência e em qual ordem. Pode ser um cron simples, Celery, Bull/Redis ou um scheduler distribuído como Apache Airflow.
• Camada de fetch com proxies: faz as requisições HTTP usando IPs rotativos. Aqui entra o ProxyHat, fornecendo IPs residenciais, mobile ou datacenter conforme a necessidade.
• Parser/Extrator: converte HTML ou JSON em dados estruturados. Pode usar BeautifulSoup, Selectolax, Playwright para páginas renderizadas em JS, ou APIs oficiais quando disponíveis.
• Armazenamento e alertas: guarda os preços em um banco de dados (PostgreSQL, TimescaleDB, ClickHouse) e dispara alertas quando há mudanças relevantes.

O gargalo quase sempre está na camada de fetch. É onde os bloqueios acontecem, onde a latência importa e onde a escolha de proxy determina o sucesso ou fracasso do pipeline inteiro.

Residencial vs Datacenter vs Mobile: qual proxy usar?

A escolha do tipo de proxy é a decisão mais importante para monitoramento de preços. Cada tipo tem vantagens e desvantagens específicas para este caso de uso.

Para a maioria dos casos de monitoramento de preços, proxies residenciais oferecem o melhor equilíbrio entre confiabilidade e custo. Sites como Amazon, Walmart e Ticketmaster bloqueiam faixas de IP de datacenter conhecidas quase instantaneamente, conforme descrito na documentação de bot management da Cloudflare. IPs residenciais se misturam ao tráfego orgânico, reduzindo drasticamente a taxa de bloqueio.

Proxies datacenter são úteis quando você monitora APIs públicas ou sites sem proteção anti-bot, onde a velocidade é prioritária. Proxies mobile são necessários apenas para casos específicos, como apps mobile ou sites que exigem IPs de operadoras móveis.

Implementação prática com ProxyHat

Vamos construir um pipeline básico de monitoramento de preços em Python, usando proxies residenciais do ProxyHat com rotação por requisição e sessões sticky quando necessário.

Configuração básica em Python

import requests
from urllib.parse import quote

# Credenciais ProxyHat
PROXY_USER = "user-country-US"
PROXY_PASS = "sua_senha_aqui"
PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@gate.proxyhat.com:8080"

proxies = {
    "http": PROXY_URL,
    "https": PROXY_URL,
}

def fetch_price(url, country="US"):
    user = f"user-country-{country}"
    proxy = f"http://{user}:{PROXY_PASS}@gate.proxyhat.com:8080"
    
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
        "Accept-Language": "en-US,en;q=0.9",
    }
    
    response = requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers=headers,
        timeout=15,
    )
    response.raise_for_status()
    return response.text

Neste exemplo, cada chamada fetch_price() usa um IP diferente porque não especificamos uma sessão. O ProxyHat rotaciona automaticamente o IP a cada requisição quando o parâmetro session não está presente no username.

Sessões sticky para fluxos de checkout

Alguns sites exigem que você mantenha o mesmo IP durante toda a navegação — por exemplo, ao simular um fluxo de checkout para capturar o preço final com impostos. Para isso, use o parâmetro session:

session_id = "checkout-abc123"
user = f"user-country-US-session-{session_id}"
proxy = f"http://{user}:{PROXY_PASS}@gate.proxyhat.com:8080"

# Todas as requisições com este session_id
# usarão o mesmo IP residencial

Exemplo em Node.js com axios

const axios = require('axios');

const PROXY_PASS = 'sua_senha_aqui';

async function fetchPrice(url, country = 'US') {
  const proxyUser = `user-country-${country}`;
  const proxyUrl = `http://${proxyUser}:${PROXY_PASS}@gate.proxyhat.com:8080`;
  
  const response = await axios.get(url, {
    proxy: {
      protocol: 'http',
      host: 'gate.proxyhat.com',
      port: 8080,
      auth: {
        username: proxyUser,
        password: PROXY_PASS,
      },
    },
    headers: {
      'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)',
      'Accept-Language': 'en-US,en;q=0.9',
    },
    timeout: 15000,
  });
  
  return response.data;
}

Teste rápido com curl

curl -x http://user-country-US:sua_senha@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0" \
  -H "Accept-Language: en-US,en;q=0.9" \
  https://example.com/product/123

Usando SOCKS5 para conexões que exigem baixa latência

Para casos onde o HTTP proxy não é suficiente, o ProxyHat também oferece SOCKS5 na porta 1080:

curl -x socks5://user-country-US:sua_senha@gate.proxyhat.com:1080 \
  https://example.com/api/prices

Estratégias de rotação e geo-targeting

A rotação de IPs deve ser estratégica, não aleatória. Aqui estão os padrões mais eficazes para monitoramento de preços:

Rotação por requisição

Ideal para coleta massiva de preços em catálogos grandes. Cada requisição recebe um IP novo, distribuindo o tráfego e evitando rate limits por IP. Funciona bem quando você precisa de 1000+ requisições por minuto.

Sessões sticky por produto

Quando você precisa visitar várias páginas do mesmo produto (página principal, variações, reviews), use um session ID baseado no SKU do produto. Isso mantém o mesmo IP durante toda a coleta daquele item, evitando comportamento suspeito.

sku = "ABC-123"
session_id = f"product-{sku}"
user = f"user-country-US-session-{session_id}"

Geo-targeting por país e cidade

Para capturar preços regionais com precisão, especifique país e cidade no username:

# Preço em Berlim, Alemanha
user = "user-country-DE-city-berlin"

# Preço em Tóquio, Japão
user = "user-country-JP-city-tokyo"

Consulte a lista completa de localizações disponíveis em /pt/locations.

Erros comuns e como evitá-los

1. Ignorar o robots.txt

Antes de raspas qualquer site, verifique o robots.txt. O padrão definido na RFC 9309 especifica como os crawlers devem interpretar as diretivas de acesso. Ignorar essas regras pode resultar em bloqueios automáticos e problemas legais.

2. Usar User-Agent fixo

Enviar 10.000 requisições com o mesmo User-Agent é um sinal claro de bot. Use uma lista de User-Agents realistas e rotacione-os. Bibliotecas como fake-useragent em Python ajudam, mas o ideal é combinar com headers realistas como Accept, Accept-Encoding e sec-ch-ua.

3. Não respeitar rate limits

Mesmo com proxies residenciais, fazer requisições muito rápidas para o mesmo domínio é detectável. Implemente delays aleatórios entre 2 e 5 segundos entre requisições para o mesmo site. Use filas com backoff exponencial quando receber HTTP 429.

4. Não tratar CAPTCHAs

Quando um site retorna um CAPTCHA, muitos pipelines simplesmente falham. Implemente detecção de CAPTCHA (procure por elementos como iframe[src*="captcha"] ou textos como "Are you a robot?") e faça retry com um novo IP e sessão diferente.

5. Não monitorar a taxa de sucesso

Sua infraestrutura precisa de métricas. Monitore a taxa de sucesso (status 200 vs 403/429), latência média e taxa de CAPTCHA. Se a taxa de sucesso cai abaixo de 90%, algo está errado — pode ser necessário mudar de datacenter para residencial, ou ajustar a frequência de coleta.

Arquitetura recomendada para escala

Para um pipeline que monitora 10.000+ produtos com atualização a cada 15 minutos, a arquitetura recomendada é:

1. Redis Queue como fila de URLs a visitar, com prioridades por categoria de produto.
2. Workers em Python (usando asyncio + aiohttp) ou Go, cada um com seu próprio proxy session.
3. ProxyHat residencial com rotação por requisição, geo-targeting por país.
4. PostgreSQL + TimescaleDB para armazenar séries temporais de preços com queries eficientes por janela de tempo.
5. Grafana para dashboards de taxa de sucesso, latência e distribuição de preços.

Com 50 workers concorrentes e proxies residenciais, é viável sustentar 500-1000 requisições por minuto com taxa de sucesso acima de 95% na maioria dos sites de e-commerce.

Considerações éticas e legais

Monitoramento de preços levanta questões legais que variam por jurisdição. Na UE, o GDPR restringe a coleta de dados pessoais. Nos EUA, o CFAA (Computer Fraud and Abuse Act) tem sido interpretado em casos como hiQ Labs v. LinkedIn, onde o tribunal decidiu que raspas de dados públicos não violam o CFAA — mas a jurisprudência continua evoluindo.

Práticas recomendadas:

• Respeite o robots.txt dos sites-alvo.
• Evite coletar dados pessoais de usuários (reviews com nomes, por exemplo).
• Use APIs oficiais quando disponíveis — muitos sites oferecem APIs de afiliados com dados de preços.
• Consulte os Termos de Serviço de cada site antes de implementar a coleta.

ProxyHat: configurando sua conta

Para começar com o ProxyHat, acesse o dashboard e crie suas credenciais. Você pode escolher entre planos residenciais, datacenter e mobile, com tráfego medido por GB ou IPs dedicados.

Consulte os planos e preços para escolher o tipo de proxy adequado ao seu volume de coleta. Para casos de uso de web scraping em geral, veja o detalhamento em /pt/use-cases/web-scraping. Para monitoramento de SERPs especificamente, acesse /pt/use-cases/serp-tracking.

A documentação técnica completa está disponível em docs.proxyhat.com, incluindo parâmetros avançados de geo-targeting, sticky sessions e limites de concorrência.

Resumo prático: Uma infraestrutura de monitoramento de preços em tempo real precisa de proxies residenciais com rotação inteligente, geo-targeting por país, sessões sticky para fluxos multi-página e monitoramento contínuo da taxa de sucesso. O ProxyHat fornece a camada de IPs; o resto é arquitetura.

Key Takeaways

• Proxies residenciais oferecem a melhor relação custo-benefício para monitoramento de preços em sites com proteção anti-bot.
• Use rotação por requisição para coleta massiva e sessões sticky baseadas em SKU para fluxos multi-página.
• Geo-targeting por país e cidade é essencial para capturar preços regionais com precisão.
• Monitore continuamente a taxa de sucesso — se cair abaixo de 90%, ajuste frequência, tipo de proxy ou headers.
• Respeite robots.txt, Terms of Service e regulamentações como GDPR para evitar problemas legais.