Como você constrói busca full-text sobre 100M+ de registros?

Question

IT Interview Practice · Accepted Answer

Use um search engine dedicado — **Elasticsearch/OpenSearch construído sobre um índice invertido** — alimentado a partir do seu DB de origem via **CDC**, e faça sharding do índice para escalar. Seu banco de dados primário (Postgres/MySQL) não consegue fazer busca de texto rankeada por relevância sobre centenas de milhões de linhas; um `LIKE '%term%'` escaneia toda linha. Um search engine inverte o problema.

```text
Source DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)   (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                     ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter to shards ─▶ gather ─┴─ Shard N ── ranked by BM25
```

## Índice invertido — por que é rápido

Um índice normal mapeia linha → valores. Um **índice invertido** mapeia *termo → lista de documentos que o contêm*. Buscar "database scaling" consulta duas posting lists curtas e as intersecta — O(docs correspondentes), não O(todos os docs). É isso que torna possível uma busca sub-100ms sobre 100M+ de documentos. O texto é **analisado** primeiro: tokenizado, minúsculo, com stemming ("running" → "run"), stopwords removidas — para que as consultas correspondam a variantes.

## Ingestão via CDC

Não faça dual-write (o app escreve no DB *e* no ES) — uma falha os deixa inconsistentes. Em vez disso, faça streaming das mudanças com **Change Data Capture**: o **Debezium** acompanha o write-ahead log do DB, publica as mudanças de linha no **Kafka**, e um indexer as aplica ao Elasticsearch. Isso mantém a busca **eventualmente consistente** com a origem e sobrevive a indisponibilidades do ES (os eventos fazem replay a partir do Kafka).

## Sharding e relevância

O índice é dividido em **shards** (cada um um índice Lucene autossuficiente), espalhados por nós; **réplicas** adicionam throughput de leitura e HA. Uma consulta faz scatter para todos os shards, cada um retorna seu top-k, e o coordenador faz merge. A relevância usa **BM25** por padrão — frequência do termo × frequência inversa do documento — ajustável com boosts, sinônimos e pesos de campo.

## Perspectiva de entrevista

Entrevistadores verificam se você (1) recorre à ferramenta certa em vez de `LIKE`, (2) sabe *como* o índice invertido funciona, e (3) resolve o **problema de sincronização** sem dual-writes. Bom: "usar Elasticsearch." Excelente: você nomeia CDC/Debezium para ingestão, BM25 para ranking, e aceita consistência eventual como o trade-off pela escala.

**Armadilha comum:** tratar o Elasticsearch como sua fonte de verdade. É um índice derivado — não durável/transacional como seu DB. Reconstrua-o a partir da origem quando necessário.

## Trade-offs e modos de falha

- **Consistência eventual:** a busca atrasa em relação às escritas pela latência do pipeline CDC (geralmente sub-segundo).
- **Dor de reindex:** mudanças de mapping/analyzer precisam de um reindex completo — use aliases para swaps zero-downtime.
- **Paginação profunda:** a página 10.000 é cara (scatter-gather) — use `search_after`, não `from/size`.
- **Shard quente / skew:** distribuição desigual de docs; escolha uma boa routing key e shards suficientes de antemão (eles são fixos na criação).
- **Ajuste de relevância é contínuo:** os padrões do BM25 raramente correspondem à intenção de negócio — espere iteração.

Índice invertido — por que é rápido

Ingestão via CDC

Sharding e relevância

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas