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.

Publicado: Fevereiro 2026 Tempo de leitura: 75 minutos Palavras-chave: #SystemDesign #SearchEngine #WebCrawler #Busca #IndiceInvertido #Ranking #SistemasDistribuidos #Escalabilidade #EntrevistaTecnica

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.

Sumário

• Análise de Requisitos
• Cálculos de Envelope
• Arquitetura de Alto Nível
• Design de API
• Modelagem de Dados
• Core 1: Descoberta de URLs e Crawler Frontier
• Core 2: Robots, Sitemaps e Politeness
• Core 3: Fetch, Render e Parsing
• Core 4: Canonicalização e Deduplicação
• Core 5: Link Graph e Qualidade
• Core 6: Índice Invertido, Segmentos e Compressão
• Core 7: Query Planning, Retrieval e Ranking
• Core 8: Snippets, Correção e Sugestões
• Core 9: Freshness e Indexação em Tempo Quase Real
• Core 10: Spam, Safe Search e Abuso
• Sharding, Cache e Multi-Região
• Confiabilidade e Modos de Falha
• Segurança, Privacidade e Observabilidade
• Controle de Custo
• Dicas de Entrevista
• Anti-Patterns
• Conclusão
• Referências
• Referência Rápida

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

1. Descobrir URLs via links, sitemaps, feeds, submissão e histórico de recrawl.
2. Respeitar robots.txt, robots meta, noindex, canonical hints e limites por host.
3. Baixar HTML, PDFs, imagens e formatos suportados com limites de segurança.
4. Renderizar páginas JavaScript quando o HTML estático não basta.
5. Extrair título, texto principal, headings, links, idioma, datas e structured data.
6. Canonicalizar URLs e agrupar documentos duplicados ou quase duplicados.
7. Construir link graph e sinais de qualidade.
8. Criar índice invertido comprimido com postings posicionais e campos.
9. Servir consultas textuais, frases, filtros, queries locais e queries frescas.
10. Ranquear por relevância lexical, qualidade, freshness, segurança e contexto permitido.
11. Gerar snippets, correções de digitação e sugestões.
12. Suportar indexação incremental, rebuilds batch e rollback.

Requisitos Não-Funcionais

Premissas de Escala

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.

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.

Cálculos de Envelope

Fetch/day = 10B URLs * 100KB comprimidos ~= 1PB/dia
Bandwidth médio = 1PB / 86.400 ~= 11,6GB/s
Pico 3x de crawl ~= 35GB/s

QPS médio = 20B / 86.400 ~= 231K queries/s
QPS pico 5x ~= 1,16M queries/s

Texto indexado = 50B docs * 10KB ~= 500TB
Índice invertido primário ~= 20% a 40% do texto normalizado
Postings primários ~= 100TB a 200TB
Com posições, campos, doc values, réplicas e tiers: múltiplos PB

QPS pico: 1,16M
Candidatos por query: 10.000
Scores/s: 11,6B

Conclusão: ranking precisa ser multi-estágio. O sistema recupera candidatos baratos, poda por score/qualidade, ranqueia centenas, re-ranqueia dezenas e só então gera SERP.

URLs conhecidas: 300B
Fetches/dia: 10B
Recrawl uniforme: 30 dias

Recrawl uniforme é ruim. Home pages, notícias e páginas de alta mudança merecem prioridade; páginas estáveis, duplicadas ou fracas podem esperar semanas.

Estimativa de Armazenamento Operacional

O índice não é o único custo de storage.

Raw fetch comprimido: 1PB/dia
Retencao hot de 7 dias: ~7PB
Texto extraido: 10B fetches * 10KB ~= 100TB/dia logico
Metadados e features: dezenas de TB/dia
Query logs em pico: centenas de TB/dia antes de sampling/agregacao

Raw pages podem ir para retenção curta.

Documentos indexáveis, features e snapshots de segmentos precisam de retenção maior.

Logs de query exigem política de privacidade, agregação e sampling.

Latência de Serving

Um budget p99 plausível:

Total p99: 250ms
Edge/auth: 15ms
Query planning: 10ms
Shard retrieval: 90ms
Merge global: 15ms
Ranking/re-ranking: 60ms
Snippets/safety: 40ms
Assembly: 20ms

O gargalo tende a ser fanout para shards e re-ranking.

Por isso a arquitetura precisa de deadlines.

Cada etapa deve saber quanto tempo ainda resta.

Implicação dos Números

Três conclusões caem direto dos cálculos:

1. crawler precisa de orçamento explícito;
2. indexação precisa de segmentos imutáveis e merges controlados;
3. serving precisa de poda agressiva antes de ranking caro.

Escalar máquinas sem mudar essas três decisões só aumenta a conta.

Arquitetura de Alto Nível

Princípios: separar crawl/index/serving; tratar URL e documento como identidades diferentes; politeness é invariante; serving não depende do crawler; segmentos são imutáveis; manifest versionado publica índice; freshness usa tiers; ranking é pipeline.

Design de API

type SearchVertical = "web" | "news" | "images" | "videos";

interface SearchRequest {
  query: string;
  vertical?: SearchVertical;
  locale?: string;
  language?: string;
  country?: string;
  device?: "desktop" | "mobile" | "tablet";
  safeSearch?: "off" | "moderate" | "strict";
  pageSize?: number;
  cursor?: string;
  userContext?: {
    signedIn: boolean;
    privacyMode: "standard" | "limited" | "anonymous";
  };
}

interface SearchResponse {
  queryId: string;
  correctedQuery?: string;
  rewrittenQuery?: string;
  results: Array<{
    rank: number;
    url: string;
    displayUrl: string;
    title: string;
    snippet: string;
    lastCrawledAt: string;
    resultType: "organic" | "news" | "video" | "image" | "direct_answer";
    safetyLabels: string[];
  }>;
  nextCursor?: string;
  latencyMs: number;
}

interface FrontierLeaseRequest {
  workerId: string;
  region: string;
  maxUrls: number;
  renderCapacity: "none" | "limited" | "full";
}

interface FrontierLeaseItem {
  urlId: string;
  normalizedUrl: string;
  hostKey: string;
  crawlPriority: number;
  politenessDeadline: string;
  renderHint: "skip" | "maybe" | "required";
}

interface FetchReport {
  leaseId: string;
  urlId: string;
  finalUrl: string;
  statusCode: number;
  fetchedAt: string;
  outcome: "fetched" | "not_modified" | "redirected" | "disallowed" | "timeout" | "server_error" | "too_large";
  rawObjectKey?: string;
  extractedObjectKey?: string;
  discoveredLinks?: string[];
}

APIs públicas têm semântica estável. APIs internas precisam de versão, idempotência, query IDs, lease IDs e tracing. Submeter URL não significa indexar; significa aceitar a URL para avaliação de discovery.

API de Submissão de URL

interface UrlSubmitRequest {
  url: string;
  source: "site_owner" | "api" | "feed" | "manual";
  sitemapUrl?: string;
  declaredLastModified?: string;
}

interface UrlSubmitResponse {
  accepted: boolean;
  normalizedUrl: string;
  reason?: "invalid_url" | "blocked_host" | "quota_exceeded" | "already_known";
  estimatedCrawlTier?: "high" | "normal" | "low";
}

Essa API deve exigir ownership verification para canais privilegiados.

Sem isso, vira vetor de spam e DDoS indireto contra o crawler.

API Interna do Query Planner

interface PlannedQuery {
  queryId: string;
  originalQuery: string;
  normalizedTerms: string[];
  phrases: string[][];
  requiredTerms: string[];
  optionalTerms: string[];
  filters: {
    language?: string;
    country?: string;
    safeSearch: "off" | "moderate" | "strict";
    freshnessWindow?: "hour" | "day" | "week" | "any";
  };
  retrievalPlan: Array<{
    indexTier: "fresh" | "main" | "archive";
    shardFanout: number;
    maxCandidatesPerShard: number;
  }>;
}

O planner não deve expor detalhes proprietários para o cliente.

Ele é contrato interno entre edge, retrieval e ranking.

Regras de Design de API

1. Toda query recebe queryId.
2. Todo fetch report é idempotente.
3. Todo lease tem expiração.
4. Todo manifest é imutável após publish.
5. Todo endpoint interno tem versão.
6. Todo serviço crítico propaga deadline.
7. Todo resultado de ranking carrega versão de modelo e feature set.

Essas regras parecem burocracia.

Em produção, elas tornam rollback, auditoria e debug possíveis.

Modelagem de Dados

CREATE TABLE url_record (
  url_id BIGINT PRIMARY KEY,
  normalized_url TEXT NOT NULL,
  url_hash BINARY(16) NOT NULL,
  host_key TEXT NOT NULL,
  discovered_at TIMESTAMP NOT NULL,
  discovery_source TEXT NOT NULL,
  canonical_doc_id BIGINT,
  crawl_priority DOUBLE PRECISION NOT NULL,
  next_crawl_at TIMESTAMP,
  last_crawl_at TIMESTAMP,
  last_status_code INTEGER,
  robots_state TEXT NOT NULL,
  render_hint TEXT NOT NULL,
  is_active BOOLEAN NOT NULL DEFAULT TRUE
);

CREATE INDEX idx_url_host_next ON url_record (host_key, next_crawl_at);
CREATE UNIQUE INDEX idx_url_hash ON url_record (url_hash);

CREATE TABLE document_record (
  doc_id BIGINT PRIMARY KEY,
  canonical_url TEXT NOT NULL,
  canonical_url_id BIGINT NOT NULL,
  content_hash BINARY(16) NOT NULL,
  simhash BIGINT NOT NULL,
  title TEXT,
  language TEXT,
  content_type TEXT NOT NULL,
  first_indexed_at TIMESTAMP NOT NULL,
  last_indexed_at TIMESTAMP NOT NULL,
  last_crawled_at TIMESTAMP NOT NULL,
  quality_score DOUBLE PRECISION NOT NULL,
  spam_score DOUBLE PRECISION NOT NULL,
  safe_search_level TEXT NOT NULL,
  indexable BOOLEAN NOT NULL
);

CREATE TABLE link_edge (
  source_doc_id BIGINT NOT NULL,
  target_url_id BIGINT NOT NULL,
  target_doc_id BIGINT,
  anchor_text_hash BINARY(16),
  rel_nofollow BOOLEAN NOT NULL,
  discovered_at TIMESTAMP NOT NULL,
  last_seen_at TIMESTAMP NOT NULL,
  PRIMARY KEY (source_doc_id, target_url_id)
);

CREATE TABLE index_segment (
  segment_id TEXT PRIMARY KEY,
  index_tier TEXT NOT NULL,
  shard_id INTEGER NOT NULL,
  generation BIGINT NOT NULL,
  doc_count BIGINT NOT NULL,
  deleted_doc_count BIGINT NOT NULL,
  object_key TEXT NOT NULL,
  checksum TEXT NOT NULL,
  published_at TIMESTAMP
);

Lição do Bigtable: registros esparsos, versionados e em escala enorme combinam bem com chaves por URL/reversed URL. Mas chaves por host podem criar ranges quentes; use salting, particionamento e filas separadas.

Tentativas de Crawl

CREATE TABLE crawl_attempt (
  attempt_id BIGINT PRIMARY KEY,
  url_id BIGINT NOT NULL,
  lease_id TEXT NOT NULL,
  worker_id TEXT NOT NULL,
  started_at TIMESTAMP NOT NULL,
  finished_at TIMESTAMP,
  status_code INTEGER,
  outcome TEXT NOT NULL,
  fetch_duration_ms INTEGER,
  render_duration_ms INTEGER,
  bytes_downloaded BIGINT,
  raw_object_key TEXT,
  extracted_object_key TEXT
);

CREATE INDEX idx_crawl_attempt_url_time
  ON crawl_attempt (url_id, started_at DESC);

Separar url_record de crawl_attempt evita sobrescrever histórico útil.

Histórico de tentativas alimenta backoff, politeness, detecção de hosts instáveis e priorização de recrawl.

Clusters Canônicos

CREATE TABLE canonical_cluster (
  cluster_id BIGINT PRIMARY KEY,
  canonical_doc_id BIGINT NOT NULL,
  representative_url TEXT NOT NULL,
  cluster_hash BINARY(16) NOT NULL,
  member_count INTEGER NOT NULL,
  updated_at TIMESTAMP NOT NULL
);

CREATE TABLE canonical_cluster_member (
  cluster_id BIGINT NOT NULL,
  url_id BIGINT NOT NULL,
  doc_id BIGINT,
  match_type TEXT NOT NULL,
  confidence DOUBLE PRECISION NOT NULL,
  PRIMARY KEY (cluster_id, url_id)
);

Cluster canônico resolve o fato de que várias URLs podem representar o mesmo documento.

Isso reduz bloat no índice e melhora diversidade na SERP.

Logs de Query e Impressão

CREATE TABLE query_log (
  query_id TEXT PRIMARY KEY,
  normalized_query TEXT NOT NULL,
  locale TEXT,
  country TEXT,
  device TEXT,
  safe_search TEXT NOT NULL,
  served_at TIMESTAMP NOT NULL,
  latency_ms INTEGER NOT NULL,
  result_count INTEGER NOT NULL,
  index_manifest_id TEXT NOT NULL,
  cache_hit BOOLEAN NOT NULL
);

CREATE TABLE result_impression (
  query_id TEXT NOT NULL,
  rank INTEGER NOT NULL,
  doc_id BIGINT NOT NULL,
  score DOUBLE PRECISION NOT NULL,
  clicked BOOLEAN,
  dwell_time_ms INTEGER,
  PRIMARY KEY (query_id, rank)
);

Esses logs são poderosos e perigosos.

Eles alimentam avaliação, ranking, debugging e detecção de regressão.

Também podem expor intenção sensível do usuário.

Retenção, acesso e agregação precisam ser tratados como parte do design.

Escolha de Chaves

Use chaves diferentes para problemas diferentes.

Um erro comum é tentar usar URL como identidade única de tudo.

URL é endereço.

Documento é conteúdo.

Cluster é equivalência.

Segmento é representação de serving.

Core 1: Descoberta de URLs e Crawler Frontier

Crawler frontier decide o que baixar, quando, por quem e com qual custo. Não é uma fila FIFO.

Fontes: links, sitemaps, feeds, submissão, histórico de recrawl e feeds confiáveis. Riscos: spam, espaços infinitos de URL, sitemaps mentirosos, parâmetros de tracking e retry storms.

crawl_priority =
  0.35 * host_quality
+ 0.20 * url_importance
+ 0.15 * expected_change_rate
+ 0.10 * freshness_demand
+ 0.10 * sitemap_confidence
+ 0.05 * historical_fetch_success
- 0.20 * spam_risk
- 0.10 * duplicate_risk
- 0.10 * crawl_cost

Use filas por tier: fresh, recrawl normal, exploração, long-tail, retry e render-required. Cada fila precisa de budget. Sem budget, spam ou notícias podem tomar o sistema inteiro.

Fontes de Descoberta

Leases e Recuperação

Workers não devem remover URLs da fila de forma definitiva.

Eles recebem leases.

Se o worker morre, o lease expira.

Depois disso, a frontier pode reagendar a URL.

Esse modelo evita trabalho perdido e reduz duplicidade.

Falhas da Frontier

Frontier madura não pergunta só "posso baixar?".

Ela pergunta "vale baixar agora?".

Core 2: Robots, Sitemaps e Politeness

Robots e politeness são requisitos de corretude. Um crawler ruim causa dano fora da sua empresa.

Política comum: robots 2xx é parseado e cacheado; 404 significa ausência de arquivo; 5xx reduz ou pausa crawl; timeout gera retry cauteloso; arquivo gigante é limitado. Robots não é segurança, é protocolo de crawling.

Sitemaps ajudam discovery, mas não garantem crawl, indexação ou ranking. Avalie confiança: lastmod bate com mudanças reais? URLs retornam 200? Há muitos 404? Todo lastmod é "agora"? Há duplicatas demais?

Politeness usa token bucket por host e às vezes por domínio registrável. Taxa cai com 5xx, timeout e latência alta; sobe devagar com saúde comprovada.

Política de Robots

Robots precisa ser cacheado com TTL.

TTL curto aumenta fetches de robots.

TTL longo pode respeitar regras antigas por tempo demais.

O sistema deve permitir invalidação para sites importantes e mudanças verificadas.

Sitemaps Como Sinal, Não Como Ordem

Um sitemap pode apontar milhões de URLs.

Isso não significa que todas merecem crawl imediato.

Use sitemaps para priorizar descoberta, não para abrir mão de ranking de crawl.

Sinais bons:

• lastmod consistente com mudanças reais;
• baixa taxa de 404;
• baixa taxa de duplicatas;
• boa taxa de indexabilidade;
• URLs canônicas e limpas.

Sinais ruins:

• todo lastmod igual ao horário atual;
• muitos parâmetros sem valor;
• muitas páginas thin;
• muitos redirects;
• muitos soft-404.

Crawl Budget Por Host

host_budget =
  base_rate
  * health_factor
  * trust_factor
  * demand_factor
  * change_rate_factor

health_factor cai com 5xx, timeout e latência.

trust_factor cai com spam e sitemap ruim.

demand_factor sobe quando usuários procuram conteúdo daquele host.

change_rate_factor sobe quando o conteúdo muda de verdade.

Core 3: Fetch, Render e Parsing

Fetch envolve DNS, TLS, redirects, conditional GET, content-type, limites de bytes, rendering seletivo, parsing e relatório idempotente.

Renderizar tudo é caro. Renderize quando HTML tem pouco texto, host historicamente depende de JS, página é valiosa ou dados estruturados aparecem após JS. Pule quando a página é baixa prioridade, excede CPU/rede, bloqueia recursos ou parece abusiva.

Parser emite: título, descrição, texto principal, boilerplate score, idioma, canonical tag, links, media refs, robots meta, content hash, simhash, structured data e features de segurança.

Pipeline de Fetch

1. Resolver DNS com cache.
2. Bloquear IPs privados e faixas proibidas.
3. Abrir conexão com timeout.
4. Enviar conditional GET com ETag/Last-Modified quando disponível.
5. Seguir redirects com limite.
6. Validar content-type e tamanho.
7. Salvar payload bruto.
8. Decidir renderização.
9. Extrair texto, links e metadados.
10. Emitir relatório idempotente.

Budget de Render

Render farm precisa ser isolada.

Páginas não confiáveis rodam JavaScript arbitrário.

Use sandbox, containers, rede restrita, patching frequente e descarte de estado entre páginas.

Parsing Não É Perfeito

HTML real é quebrado.

Boilerplate muda por site.

Datas podem ser ambíguas.

Texto visível pode divergir de DOM.

Por isso parser deve produzir score de confiança, não só campos.

Quando confiança é baixa em página importante, renderize ou mande para pipeline especializado.

Core 4: Canonicalização e Deduplicação

A web duplica tudo: HTTP/HTTPS, www/bare, tracking params, sessão, print pages, mobile, AMP, cópias sindicadas e variações locais.

Normalização: lowercase em scheme/host, remover portas padrão, normalizar encoding, ordenar parâmetros seguros, remover tracking conhecido, resolver dot segments e preservar case de path quando necessário.

Sinais: redirect forte, rel=canonical forte porém abusável, sitemap médio, links internos médio, hash exato forte, simhash/minhash médio-forte, idioma/região contextual.

Escolha canonical por HTTPS, status estável, conteúdo completo, links internos/externos, segurança, locale e hints consistentes. Canonicalização não é deletar alternates; variantes podem servir para país, idioma, device ou query exata.

Normalização de URL

Regras úteis:

1. lowercase em scheme e host;
2. remover portas padrão;
3. normalizar percent encoding;
4. resolver . e .. no path;
5. remover tracking parameters conhecidos;
6. ordenar parâmetros seguros;
7. preservar path case quando o servidor pode diferenciar;
8. normalizar IDN de forma consistente;
9. limitar tamanho de URL;
10. detectar padrões infinitos.

Over-normalization causa bug difícil.

/Produto e /produto podem ser páginas diferentes.

?page=2 não é tracking.

?sort=price pode alterar conteúdo.

Detecção de Near-Dupe

Camadas:

• hash exato do conteúdo extraído;
• simhash para texto semelhante;
• minhash por shingles;
• similaridade de título;
• canonical tag;
• redirects;
• estrutura de links internos.

Páginas duplicadas não são sempre lixo.

Uma versão mobile, uma versão traduzida e uma versão regional podem ser úteis em contextos diferentes.

O cluster guarda alternates para serving contextual.

Escolha de Representante

Core 5: Link Graph e Qualidade

Links são discovery e sinal de importância. O paper original do Google explorava estrutura de hipertexto para melhorar busca; a ideia ainda é central, com muito mais defesa contra abuso.

Edge bom tem source doc, target URL/doc, anchor, texto ao redor, rel, seção da página, posição, first/last seen e internal/external. Qualidade combina reputação de host, originalidade, profundidade, links, histórico, risco de malware/phishing, spam, excesso de afiliados e qualidade do cluster.

Link analysis costuma ser offline/nearline porque o grafo é enorme, iterativo e sensível a filtros de spam. Use snapshots reprodutíveis e sinais frescos locais para páginas novas.

Features de Link

Não armazene só source e target.

Guarde:

• anchor text;
• texto ao redor do link;
• posição no documento;
• seção da página;
• rel=nofollow, ugc e sponsored;
• first seen e last seen;
• internal/external;
• redirect final;
• confiança do host de origem.

Anchor text é forte para queries navegacionais.

Também é vetor clássico de manipulação.

Por isso o ranking deve descontar links de baixa confiança.

Qualidade Estática

Sinais úteis:

Qualidade estática não substitui relevância lexical.

Uma página excelente sobre assunto errado não deve rankear.

Uma página lexicalmente perfeita com baixa confiança também não deve subir sem limites.

Ranking bom combina as duas dimensões.

Core 6: Índice Invertido, Segmentos e Compressão

Índice invertido mapeia termo para documentos. Em busca web, postings carregam campos, posições, frequências e payloads.

termo: "busca"
  df: 120.000.000
  postings:
    doc 101, tf=4, fields=title/body, pos=[1, 18, 44, 90]
    doc 140, tf=1, fields=body, pos=[55]

Campos úteis: title, headings, body, anchor text, URL tokens, structured data, alt text, idioma e datas. Compressão usa delta docID, blocos, skip pointers, variable byte, bit packing, frame-of-reference e técnicas SIMD-friendly. Compressão economiza disco e melhora cache/memória.

Segmentos devem ser imutáveis. Updates viram novo segmento + delete bitset. Publicação é troca de manifest. Rollback é voltar o ponteiro para último manifest bom.

Tiers: real-time em segundos, fresh em minutos, daily em horas, main em dias, archive frio. Query "terremoto hoje" consulta fresh + main; query "binary search" pode ficar no main.

Modos de Construção do Índice

Full rebuild é inevitável em mudanças estruturais.

Exemplo: trocar tokenizer, adicionar posições por campo ou mudar docID layout.

Incremental é caminho normal para o dia a dia.

Micro-index existe para freshness.

Backfill evita esperar o próximo rebuild global.

Analyzer Pipeline

HTML -> texto visivel -> idioma -> tokenizacao -> normalizacao
     -> stemming/lemmatizacao seletiva -> campos -> postings

Decisões importantes:

1. detectar idioma antes de stemming;
2. preservar forma exata para frase e título;
3. normalizar acentos conforme idioma;
4. tratar stop words sem destruir queries exatas;
5. guardar posições para proximity;
6. separar title/body/anchor;
7. versionar analyzer.

Analyzer versionado é obrigatório.

Sem isso, um segmento antigo e um segmento novo podem interpretar termos de formas diferentes.

Segment Lifecycle

Deletes usam bitsets.

Updates viram nova versão de documento.

Merges compactam deletes, reduzem número de segmentos e melhoram locality.

Merge agressivo reduz latência de query, mas consome CPU/IO.

Merge preguiçoso melhora velocidade de publicação, mas aumenta fanout interno.

Resposta prática: tiered merge com budget explícito e feedback de latência.

Core 7: Query Planning, Retrieval e Ranking

Query planner normaliza, entende intenção, aplica rewrites e decide quais shards/tier consultar.

Tipos: navegacional, informacional, transacional, fresh, local, frase exata, site-scoped e filtros. Retrieval básico pega postings, intersecta/une, calcula BM25-like, aplica qualidade/freshness, mantém topK por shard e faz merge global. Retrieval otimizado usa skip, champion lists, block max WAND, early termination, tiered indexes e cache de blocos.

Ranking usa relevância lexical, qualidade, freshness, locale, safe search, popularidade agregada, estrutura de conteúdo, diversidade e sinais anti-spam. Stage 1 roda em milhares, stage 2 em centenas, stage 3 em dezenas. Blending injeta news, images, videos, local pack ou direct answer só quando a intenção justifica.

Tail latency vem do fanout: se uma query toca 1.000 shards, o shard lento domina p99. Mitigue com réplicas, hedged requests, deadlines, partial results, cache e shard splitting.

Tipos de Query

Query de código não deve receber stemming agressivo.

Query médica não deve ser corrigida de forma ousada.

Query navegacional não precisa explorar muitos documentos.

O planner precisa carregar intenção para reduzir custo e erro.

Retrieval Otimizado

1. buscar dicionario dos termos
2. ordenar termos por seletividade
3. ler blocos de postings comprimidos
4. aplicar skip/block max
5. calcular score parcial
6. podar candidatos impossiveis
7. manter topK por shard
8. retornar score bounds para merge

Block max WAND e técnicas similares evitam pontuar documentos que não podem entrar no topK.

Isso é diferença entre busca teórica e busca de produção.

Famílias de Features de Ranking

Ranking precisa ser auditável.

Quando um resultado ruim sobe, o time precisa saber se foi lexical, freshness, link signal, modelo, spam bypass ou blending.

Por isso cada estágio deve logar scores intermediários em amostras controladas.

Core 8: Snippets, Correção e Sugestões

SERP boa não é só ordenação. Snippet ajuda o usuário a escolher resultado.

Snippet deve preferir passagem com termos da query, preservar frases, evitar boilerplate, respeitar no-snippet, filtrar texto inseguro e lidar com idiomas. Correção usa dicionário do corpus, logs agregados, distância de edição, teclado, fonética, entidades e contexto. Seja conservador com nomes, código, termos médicos, jurídicos e queries entre aspas.

Sugestões precisam de filtro contra adulto em modo estrito, assédio, dados pessoais, malware, ilegalidade e campanhas de spam. Não exponha trending query crua.

Seleção de Snippet

Um snippet bom não é sempre a meta description.

Meta description pode ser genérica, desatualizada ou manipulada.

Pipeline prático:

1. recuperar passagens candidatas;
2. pontuar cobertura dos termos;
3. preferir frases completas;
4. remover boilerplate;
5. aplicar safe search;
6. respeitar nosnippet;
7. destacar termos;
8. cachear por query/doc quando fizer sentido.

Correção Conservadora

Correção agressiva melhora typos comuns.

Também destrói intenção rara.

Exemplos de cuidado:

• nomes próprios;
• identificadores de código;
• medicamentos;
• termos jurídicos;
• queries entre aspas;
• domínios e URLs;
• siglas.

Quando confiança é média, mostre resultados para a correção e permita voltar à query original.

Quando confiança é baixa, apenas sugira.

Core 9: Freshness e Indexação em Tempo Quase Real

Freshness é seletiva. A maioria das páginas não precisa entrar em segundos; algumas queries precisam.

Sinais: feeds, sitemap lastmod, RSS/Atom, histórico de mudança, spikes de query, publishers confiáveis e entidades/eventos. Fresh index é pequeno, rápido, caro por doc, tem retenção curta e merge posterior para main.

Falha: se fresh indexing cai, sirva main index com métrica de degradação. Não derrube busca inteira por perda de freshness.

Query Deserves Freshness

Nem toda query recente merece resultado novo.

Classificador QDF pode usar:

• spike de volume;
• entidades temporais;
• termos como "hoje", "agora", "ao vivo";
• categoria da entidade;
• histórico de clique em resultados recentes;
• presença em news feeds;
• sazonalidade.

Exemplos frescos:

Exemplos evergreen:

Freshness é feature condicional, não boost global.

Boost global favorece páginas novas ruins contra páginas antigas excelentes.

Core 10: Spam, Safe Search e Abuso

Busca é adversarial. Qualquer sinal que gera valor será atacado.

Safe search precisa ser configurável, auditável, regionalmente consciente e medido por falso positivo/negativo. Use defesa em profundidade: crawl, index, rank, serving, review e feedback de publisher.

Onde Aplicar Controles de Abuso

Aplicar só no ranking é tarde.

Spam já consumiu crawl, storage e indexação.

Aplicar só no crawler também é insuficiente.

Páginas legítimas podem ser comprometidas depois.

Safe Search

Safe search precisa separar categorias.

Adulto explícito, violência gráfica, malware, phishing e conteúdo ilegal não são a mesma classe.

Cada classe tem política, threshold e tratamento regional.

Também precisa haver auditoria para falsos positivos.

Overblocking em saúde, educação ou notícias pode degradar qualidade e confiança.

Sharding, Cache e Multi-Região

Sharding por doc ID/hash balanceia storage, mas query toca muitos shards. Term sharding reduz leitura por termo, mas complica multi-termo. Host sharding ajuda crawler, mas é ruim para serving. Em web search, doc sharding + otimização de fanout costuma ser escolha prática.

Cache: result cache por query/locale/safe mode; query plan cache; postings block cache; dictionary cache; feature cache; snippet cache. Cache ajuda hot queries, mas a base precisa sobreviver a misses.

Serving deve ser active-active regional. Índices publicados replicam para regiões. Control plane guarda manifest ativo, configs de experimento, políticas, remoções legais e quotas globais. Lição do Spanner: use consistência forte onde correção importa; use eventual onde escala/latência importam.

Estratégias de Sharding

Em web search, doc sharding costuma vencer para serving geral.

O sistema compensa fanout com pruning, cache, réplicas e deadlines.

Consistent Hashing

Consistent hashing reduz movimentação quando adicionamos shards.

Mas ele não resolve tudo.

Use virtual nodes, split manual de hosts gigantes, detecção de hot shard e routing map versionado.

Separar shard lógico de partição física ajuda rebalanceamento.

Multi-Região

Query serving deve ficar perto do usuário.

Crawl pode ser distribuído, mas politeness precisa de visão global por host.

Index build pode ser centralizado ou regional.

O ponto essencial: cada região precisa servir o último manifest bom sem depender do crawler ou do builder.

Falhas esperadas:

• região inteira fora;
• manifest ruim;
• upload de segmento corrompido;
• modelo de ranking com regressão;
• control plane particionado;
• fresh tier atrasado.

Confiabilidade e Modos de Falha

Ordem de degradação em serving: pular re-ranker caro, simplificar snippets, reduzir fanout de tiers não críticos, usar feature cache, desativar vertical blending incerto, servir lexical+static rank e aceitar partial results com logging.

Publish seguro: checksum, regressão de queries, comparação de overlap, latência, safety, deltas de doc count, deleções, canary por região e rollback pointer.

Evite retry amplification: deadlines, retries limitados, jitter, token buckets, circuit breakers, hedging só em leitura com cancelamento e load shedding.

Ordem de Degradação

Degradação precisa ser intencional.

Sem ordem definida, cada serviço falha de um jeito e a SERP vira loteria.

Publish Seguro de Índice

Antes de ativar manifest:

1. validar checksums;
2. comparar contagem de docs;
3. rodar query set de regressão;
4. medir overlap com índice anterior;
5. checar safety labels;
6. canary em região pequena;
7. observar p99 e empty result rate;
8. manter rollback pointer.

Rollback de índice deve ser troca de ponteiro, não rebuild emergencial.

Segurança, Privacidade e Observabilidade

Crawler precisa bloquear IPs privados, limitar bytes/CPU, sandboxar renderers, isolar parsers, lidar com decompression bombs, redirects infinitos, DNS rebinding, PDFs maliciosos e content-type confuso.

Query logs são dados sensíveis: podem revelar saúde, localização, intenção e identidade. Use retenção curta, agregação, pseudonimização, controle de acesso, auditoria e revisão de privacidade para features.

SLOs: query availability 99,99%; p99 <= 250ms; p99.9 <= 800ms; empty result rate por locale; shard timeout; fresh publish latency; robots compliance; bad manifest rollback em minutos. Métricas de qualidade: long click, reformulation, abandonment, julgamento humano, spam no topK, safe search false positive/negative e satisfação com snippets.

Observabilidade Por Plano

Tracing de Query

Cada query amostrada deve permitir reconstruir:

• região de serving;
• manifest ativo;
• plano de retrieval;
• shards consultados;
• timeouts;
• candidatos retornados;
• versão do ranker;
• filtros aplicados;
• snippet path;
• cache hits.

Sem isso, debugging vira tentativa de reproduzir um sistema probabilístico depois que o estado mudou.

Alertas Que Importam

Alertas úteis combinam sintoma e impacto.

CPU alta sozinho é ruído.

p99 alto + shard timeout + queda de long click é incidente real.

Para busca, alertas devem cruzar infraestrutura e qualidade.

Controle de Custo

Maiores custos: bandwidth de crawl, render CPU, parser CPU, object storage, index storage, query fanout, inferência de ranking e analytics.

Métrica útil:

useful_index_yield =
  docs canonicos indexados com impressoes
  / fetch attempts totais

Se um host consome 2% do crawl budget e gera 0,001% de impressões úteis, revise.

Controle de Render

Render é uma das formas mais fáceis de gastar CPU.

Política prática:

• renderizar hosts que precisam de JS e geram valor;
• amostrar render em hosts desconhecidos;
• desligar render em páginas duplicadas;
• impor timeout duro;
• separar fila render-required;
• medir ganho de extração por host.

Se render não aumenta texto útil, links úteis ou dados estruturados, ele deve perder prioridade.

Controle de Logs

Logs são caros e sensíveis.

Use:

• sampling por classe de query;
• retenção por tier;
• agregação antes de analytics amplo;
• acesso restrito a logs brutos;
• remoção de identificadores quando possível;
• dashboards baseados em métricas derivadas.

Economizar log sem perder debug exige amostragem inteligente, não corte cego.

Dicas de Entrevista

Fluxo forte: esclarecer escopo, declarar escala, separar crawl/index/serving, explicar frontier/politeness, canonicalização, índice invertido, query fanout, ranking, freshness, sharding, cache, abuso, privacidade e rollback.

Frases senior: "URL e documento são identidades diferentes"; "politeness é corretude"; "segmentos imutáveis publicados por manifest"; "freshness usa tiers"; "ranking é staged"; "tail latency vem do fanout"; "crawl budget é alocado, não só escalado".

Atalho de whiteboard:

Crawl Plane -> Indexing Plane -> Serving Plane
Policy/Quality atravessa os três

Anti-Patterns

1. "Use Elasticsearch" como resposta completa. Lucene/Elasticsearch ajudam no índice, não resolvem crawler, dedupe, link graph, ranking, safe search e multi-região.
2. Crawling uniforme. A web muda em ritmos diferentes.
3. Renderizar tudo. Custo explode.
4. Ignorar canonicalização. Duplicatas viram problema de relevância.
5. Um modelo único de ranking. Caro, lento e difícil de depurar.
6. Sem fresh tier. Notícias ficam stale ou o main index vira gargalo.
7. Retries cegos. Você derruba hosts e a própria frota.
8. Tratar query log como inofensivo. É dado sensível.
9. Serving depender do crawler. Sirva último índice bom.
10. Sem rollback. Índice ruim e modelo ruim acontecem.

Conclusão

Um motor de busca web é um sistema distribuído sob pressão de escala, custo, abuso e produto. A solução não é um banco, uma fila ou um modelo. É uma cadeia de decisões controladas: quais URLs merecem crawl, quais páginas podem ser buscadas, qual documento é canônico, qual conteúdo entra no índice, quais shards respondem, quais candidatos recebem ranking caro e quais resultados são seguros.

O desenho senior separa planos, usa frontier com budget, respeita robots, faz dedupe antes de inflar o índice, publica segmentos imutáveis, opera tiers de freshness, ranqueia em estágios, observa sistema e relevância juntos, protege logs e degrada sem apagar a busca.

Essa é a diferença entre "busca textual" e um motor de busca real.

Referências

• Google Search Central: How Search Works
• Google Search Central: Introduction to robots.txt
• Google Search Central: Sitemaps
• Google Search Central: Canonicalization
• Google Search Central: JavaScript SEO basics
• The Anatomy of a Large-Scale Hypertextual Web Search Engine
• Bigtable: A Distributed Storage System for Structured Data
• Spanner: Google's Globally-Distributed Database
• Apache Lucene Core
• Introduction to Information Retrieval
• Introduction to Information Retrieval: Index Compression
• Introduction to Information Retrieval: Building an Inverted Index

Referência Rápida

Budget p99 250ms:
Edge/auth: 15ms
Query planning: 10ms
Shard retrieval: 90ms
Merge: 15ms
Ranking: 60ms
Snippets/safety: 40ms
Assembly: 20ms

Uma frase: motor de busca é ingestão crawl-budgeted e policy-aware alimentando índices comprimidos imutáveis, servidos por fanout com deadline e ranking em estágios sob pressão constante de abuso.