Scrapy em produção: arquitetura, escala e conformidade com LGPD

Scrapy é um framework Python assíncrono para rastreamento e extração de dados estruturados em larga escala. Sua arquitetura de spiders, middlewares e pipelines organiza o fluxo de coleta de forma reprodutível, com concorrência alta e baixo custo por requisição — o que o torna a escolha padrão para inteligência competitiva, precificação dinâmica e monitoramento de mercado no Brasil.

Este guia cobre decisões de arquitetura, padrões de implementação, integração com renderização headless, distribuição com scrapy-redis e conformidade com a LGPD — com exemplos de código e um checklist operacional para produção.

Por que escolher Scrapy para crawlers em larga escala

Scrapy foi concebido para rastreamento assíncrono: o modelo não-bloqueante permite centenas de requisições simultâneas sem overhead de threads. Isso o diferencia de soluções síncronas como Requests + BeautifulSoup, adequadas para tarefas ad hoc, mas ineficientes para coleções massivas.

Critério de decisão por ferramenta:

Para iniciar: crie o projeto com scrapy startproject, valide seletores interativamente com scrapy shell e adicione pipelines para limpeza, deduplicação e integração com S3 ou bancos de dados. Documente todas as configurações em settings.py para garantir reprodutibilidade e auditoria.

Arquitetura prática: spiders, middlewares e pipelines

O fluxo central do Scrapy segue uma sequência clara: o Scheduler despacha URLs, os Downloader Middlewares tratam cabeçalhos e proxies, o Spider extrai os dados, e os Item Pipelines validam e persistem. Essa separação de responsabilidades facilita testes unitários e observabilidade por camada.

Workflow mínimo para um job em produção:

1. Agendar URLs no Scheduler ou via fila externa, com metadados de proxy ou renderização embutidos em cada request.
2. Middlewares aplicam rotação de User-Agent, proxies residenciais e retries com backoff exponencial.
3. O Spider extrai itens e os encaminha para pipelines de limpeza e persistência.

Configuração de referência para settings.py:

# settings.py — valores iniciais conservadores, ajuste conforme sinais do alvo
CONCURRENT_REQUESTS = 32
AUTOTHROTTLE_ENABLED = True
DOWNLOAD_DELAY = 0.5

DOWNLOADER_MIDDLEWARES = {
    'myproject.middlewares.RotatingProxyMiddleware': 543,
}

FEEDS = {
    's3://bucket/path/data.jsonl': {'format': 'jsonlines'}
}

Monitore latência por request, taxa de erros HTTP e items por segundo para guiar ajustes de CONCURRENT_REQUESTS e AutoThrottle. Comece conservador e escale com base em dados reais do alvo.

Scrapy + renderização headless: quando e como integrar

Use renderização headless apenas quando o conteúdo necessário existir exclusivamente após execução de JavaScript no cliente. Para páginas que expõem dados via chamadas XHR ou JSON embutido no HTML, intercepte as chamadas de API diretamente — é mais rápido e barato.

A integração recomendada é o scrapy-playwright, que mantém o fluxo nativo do Scrapy e renderiza apenas as URLs marcadas explicitamente:

yield scrapy.Request(
    url="https://site-dinamico.example",
    meta={"playwright": True, "playwright_include_page": True},
    callback=self.parse
)

Boas práticas ao combinar os dois:

• Defina PLAYWRIGHT_MAX_CONTEXTS para evitar estouro de memória em crawls longos.
• Meça o tempo médio de navegação e compare o custo por página antes e depois da integração.
• Reserve a renderização para URLs que falham com scraping direto — não aplique globalmente.

Escala, distribuição e observabilidade em produção

Para passar do PoC para produção distribuída, externalize a fila de URLs e o estado do crawl. O scrapy-redis substitui o Scheduler padrão por uma fila Redis compartilhada, permitindo múltiplos workers stateless sem duplicação de trabalho.

Padrão operacional recomendado:

• Fila centralizada no Redis com deduplicação por fingerprint de URL.
• Workers stateless escaláveis horizontalmente via containers.
• Pipelines que escrevem resultados em S3 ou bases analíticas (BigQuery, Redshift, ClickHouse).

Métricas essenciais para monitorar:

• Requests por segundo e items por segundo (throughput real).
• Taxa de erros HTTP por código (4xx, 5xx separados).
• Latência média por request e por domínio alvo.
• Tamanho da fila pendente (sinal de gargalo no Downloader).

Observabilidade mínima: exponha métricas via Prometheus, agregue logs estruturados (JSON) e configure alertas para spikes de 4xx/5xx. Automatize retries com backoff exponencial e registre todas as exceções para análise posterior.

Mitigação de bloqueios, proxies e CAPTCHAs

O primeiro passo é identificar o padrão de bloqueio: respostas 403, JavaScript challenges ou redirecionamentos para páginas de verificação. Teste com IPs de diferentes regiões e registre em qual volume ou frequência o bloqueio é acionado — isso define a estratégia de proxy.

Estratégia por tipo de bloqueio:

• Rate limiting simples: DOWNLOAD_DELAY com jitter randômico e AutoThrottle.
• Bloqueio por IP: pool de proxies datacenter com rotação por request.
• Fingerprinting avançado: proxies residenciais com rotação de User-Agent e headers realistas.
• CAPTCHA: evite páginas que os acionam; quando inevitável, use serviços de resolução ou offload para provedores especializados.

Provedores como Bright Data, Oxylabs e ScrapFly oferecem pools de proxies e rendering gerenciado com integração direta a pipelines Scrapy. Avalie SLA, latência e custo por request antes de escolher — o custo escala rapidamente em crawls de alto volume.

Documente a política de escalonamento: se o bloqueio persistir após N tentativas por IP, mova a URL para uma fila de investigação manual em vez de continuar tentando automaticamente.

Conformidade legal e LGPD para scraping no Brasil

Princípio operacional: verifique a disponibilidade de API pública antes de iniciar qualquer projeto de scraping. APIs reduzem risco jurídico, melhoram qualidade dos dados e eliminam a necessidade de lidar com bloqueios. Quando não houver API, respeite robots.txt e documente os limites de taxa no runbook do projeto.

Obrigações práticas sob a LGPD:

• Minimize a coleta de dados pessoais ao estritamente necessário para a finalidade declarada.
• Aplique pseudonimização ou anonimização antes de persistir dados que possam identificar pessoas.
• Registre a base legal para cada tipo de dado coletado (legítimo interesse, consentimento, etc.).
• A ANPD publica orientações e canais de denúncia; alinhe procedimentos internos com essas diretrizes.

Sobre risco jurídico: o caso hiQ v. LinkedIn (EUA) estabeleceu que scraping de dados públicos pode ser permitido em certas jurisdições, mas o contexto brasileiro tem especificidades próprias. Em projetos comerciais de alto risco, consulte assessoria jurídica e prefira contratos ou parcerias de dados quando possível.

Checklist operacional para o Brasil:

• Preferir APIs oficiais quando disponíveis.
• Evitar coleta de PII; aplicar pseudonimização quando inevitável.
• Documentar rotinas, limites de taxa e responsáveis técnicos no runbook.
• Manter plano de auditoria e resposta a incidentes para comunicar vazamentos ou reclamações à ANPD.
• Revisar robots.txt e Termos de Serviço do alvo antes de cada novo projeto.

Próximos passos para colocar seu crawler em produção

Adotar padrões claros transforma o Scrapy em uma plataforma robusta para coleta responsável de dados. O caminho recomendado:

1. Comece com um spider simples, valide seletores com scrapy shell e meça throughput real.
2. Adicione middlewares de proxy e retry antes de escalar — não depois.
3. Integre scrapy-playwright apenas para URLs que exigem JS; mantenha o restante no fluxo padrão.
4. Migre para scrapy-redis quando um único nó não for suficiente.
5. Implemente observabilidade (Prometheus + logs estruturados) antes do roll-out em produção.
6. Execute um benchmark controlado para calibrar CONCURRENT_REQUESTS e custos de proxy antes de escalar definitivamente.