¿Cómo construyes búsqueda full-text sobre 100M+ de registros?

Question

IT Interview Practice · Accepted Answer

Usa un motor de búsqueda dedicado — **Elasticsearch/OpenSearch construido sobre un índice invertido** — alimentado desde tu DB de origen vía **CDC**, y fragmenta el índice para escalar. Tu base de datos primaria (Postgres/MySQL) no puede hacer búsqueda de texto rankeada por relevancia sobre cientos de millones de filas; un `LIKE '%term%'` escanea cada fila. Un motor de búsqueda invierte el 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 qué es rápido

Un índice normal mapea fila → valores. Un **índice invertido** mapea *término → lista de documentos que lo contienen*. Buscar "database scaling" consulta dos posting lists cortas y las intersecta — O(docs que coinciden), no O(todos los docs). Esto es lo que hace posible la búsqueda sub-100ms sobre 100M+ de documentos. El texto se **analiza** primero: tokenizado, en minúsculas, stemming ("running" → "run"), stopwords descartadas — para que las queries coincidan con las variantes.

## Ingesta vía CDC

No hagas dual-write (la app escribe DB *y* ES) — un fallo los deja inconsistentes. En su lugar, transmite los cambios con **Change Data Capture**: **Debezium** sigue el write-ahead log de la DB, publica los cambios de fila a **Kafka**, y un indexer los aplica a Elasticsearch. Esto mantiene la búsqueda **eventualmente consistente** con el origen y sobrevive a caídas de ES (los eventos hacen replay desde Kafka).

## Sharding y relevancia

El índice se divide en **shards** (cada uno un índice Lucene autocontenido), repartidos entre nodos; las **réplicas** añaden throughput de lectura y HA. Una query hace scatter a todos los shards, cada uno devuelve su top-k, y el coordinator hace merge. La relevancia usa **BM25** por defecto — frecuencia del término × frecuencia inversa de documento — ajustable con boosts, sinónimos y pesos de campo.

## Perspectiva de la entrevista

Los entrevistadores comprueban si (1) recurres a la herramienta correcta en lugar de `LIKE`, (2) sabes *cómo* funciona el índice invertido, y (3) resuelves el **problema de sincronización** sin dual-writes. Bueno: "usa Elasticsearch." Excelente: nombras CDC/Debezium para la ingesta, BM25 para el ranking, y aceptas la eventual consistency como la compensación por la escala.

**Trampa común:** tratar Elasticsearch como tu source of truth. Es un índice derivado — no duradero/transaccional como tu DB. Reconstrúyelo desde el origen cuando sea necesario.

## Compensaciones y modos de fallo

- **Eventual consistency:** la búsqueda va con retraso respecto a las escrituras por la latencia del pipeline CDC (normalmente sub-segundo).
- **Dolor del reindex:** los cambios de mapping/analyzer necesitan un reindex completo — usa aliases para swaps sin downtime.
- **Paginación profunda:** la página 10.000 es cara (scatter-gather) — usa `search_after`, no `from/size`.
- **Shard caliente / sesgo:** distribución desigual de docs; elige una buena routing key y suficientes shards por adelantado (son fijos en la creación).
- **El tuning de relevancia es continuo:** los defaults de BM25 rara vez coinciden con la intención de negocio — espera iteración.

Índice invertido — por qué es rápido

Ingesta vía CDC

Sharding y relevancia

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas