Projetando um Motor de Busca em Escala: Guia Completo de System Design
Resumo: Um guia prático e senior para desenhar um motor de busca em escala de internet, cobrindo crawler frontier, robots.txt, sitemaps, canonicalização, deduplicação, índice invertido, ranking, snippets, freshness, sharding, multi-região, confiabilidade, abuso, privacidade e trade-offs de entrevista.
Este artigo foi publicado por completo no meu blog, com os diagramas e exemplos práticos.
link
Um motor de busca parece simples por fora: uma caixa, uma consulta e uma lista de resultados. Por dentro, o sistema precisa descobrir a web, respeitar publishers, baixar páginas sem sobrecarregar hosts, renderizar JavaScript quando necessário, extrair texto, resolver duplicatas, construir índices comprimidos, ranquear documentos sob pressão adversarial e responder em baixa latência para usuários no mundo todo.
O problema não é "guardar HTML e fazer LIKE". O problema real é alocar crawl budget, decidir o que merece freshness, separar URL de documento, consolidar canonicals, operar shards e réplicas, controlar tail latency, combater spam e continuar servindo quando crawler, indexador ou ranker degradam.
O Google Search Central descreve busca em três estágios: crawling, indexing e serving. Para system design, precisamos abrir esses estágios em subsistemas operacionais: descoberta de URLs, frontier, robots, fetch, render, parser, dedupe, link graph, index builder, segment store, query planner, retrieval, ranking, snippets, safe search, observabilidade e controle de custo.
Este artigo desenha um sistema tipo Google Search/Bing em nível de entrevista senior. Não é clone de arquitetura proprietária. Os números são premissas plausíveis para raciocínio, não afirmações sobre empresas reais.
Análise de Requisitos
Escopo: busca web pública, documentos descobertos por links/sitemaps/feeds/submissão, serving global, resultados orgânicos, safe search e freshness seletiva. Fora do escopo principal: leilão de anúncios, busca enterprise privada, geração de respostas por IA, email pessoal, inventário fechado de ecommerce e telemetry proprietária.
Requisitos Funcionais
- Descobrir URLs via links, sitemaps, feeds, submissão e histórico de recrawl.
- Respeitar robots.txt, robots meta, noindex, canonical hints e limites por host.
- Baixar HTML, PDFs, imagens e formatos suportados com limites de segurança.
- Renderizar páginas JavaScript quando o HTML estático não basta.
- Extrair título, texto principal, headings, links, idioma, datas e structured data.
- Canonicalizar URLs e agrupar documentos duplicados ou quase duplicados.
- Construir link graph e sinais de qualidade.
- Criar índice invertido comprimido com postings posicionais e campos.
- Servir consultas textuais, frases, filtros, queries locais e queries frescas.
- Ranquear por relevância lexical, qualidade, freshness, segurança e contexto permitido.
- Gerar snippets, correções de digitação e sugestões.
- Suportar indexação incremental, rebuilds batch e rollback.
Requisitos Não-Funcionais
| Requisito | Meta | Motivo |
|---|---|---|
| Disponibilidade de busca | 99,99%+ | Busca é superfície primária |
| Latência de query | p50 <= 80ms, p99 <= 250ms | Usuário espera resposta imediata |
| Freshness prioritária | segundos a minutos | Notícias e incidentes envelhecem rápido |
| Recrawl geral | horas a semanas | Crawl budget é finito |
| Politeness | obrigatório por host/site | Não sobrecarregar publishers |
| Consistência | eventual nos resultados | Forte em tudo seria caro demais |
| Segurança | alta | Conteúdo e tráfego são adversariais |
| Custo | budget explícito por tier | Crawl/ranking queimam dinheiro rápido |
Premissas de Escala
| Item | Premissa |
|---|---|
| URLs conhecidas | 300B |
| Documentos canônicos indexados | 50B |
| Fetches por dia | 10B |
| Queries por dia | 20B |
| Multiplicador de pico | 5x |
| Regiões de serving | 6 |
| Resultados orgânicos por query | 10 |
Perguntas de entrevista: é busca web, site search ou enterprise? Quais formatos entram? Safe search é obrigatório? Qual freshness esperada? Personalização entra? Ads entram? Qual QPS? Qual volume de documentos?
Métricas de Produto
Busca precisa de métricas de sistema e métricas de relevância.
Uma SERP rápida com resultados ruins ainda falha.
Uma SERP excelente que chega depois de 2 segundos também falha.
| Métrica | O que mede | Sinal de problema |
|---|---|---|
| Search success rate | usuário encontrou resposta útil | reformulações em sequência |
| Long click rate | clique com permanência | resultado promissor e útil |
| Pogo-sticking | volta rápida para a SERP | snippet enganoso ou página ruim |
| Query abandonment | saída sem clique/resposta | baixa relevância ou latência |
| Empty result rate | consultas sem resposta | cobertura ruim ou filtros agressivos |
| Fresh result coverage | documentos recentes quando necessário | notícias atrasadas |
| Safe search precision | filtro acerta conteúdo sensível | overblocking/underblocking |
| Crawl useful yield | fetch que vira valor de busca | frontier desperdiçando budget |
Escopo Que Não Devemos Misturar
Ads não entram no core.
Um leilão de anúncios tem latência, fairness, billing e compliance próprios.
Busca local também pode ser um vertical separado.
Ela depende de inventário de negócios, geocoding, horário de funcionamento e ranking geoespacial.
Busca por imagens e vídeos exige embeddings multimodais, thumbnails, transcodificação e políticas próprias.
O core deste guia é web search textual com capacidade de misturar verticais quando a query pede.
Consistência Esperada
Resultados de busca aceitam consistência eventual.
Se uma página nova aparece em uma região antes da outra, isso é tolerável na maioria dos casos.
Configuração de política não deve ser eventual sem controle.
Remoções legais, noindex, malware, safe search e ponteiros de manifest ativo exigem semântica mais forte.
Essa separação evita pagar custo de coordenação global em tudo.