Hoe bouw je full-text search over 100M+ records?

Question

IT Interview Practice · Accepted Answer

Gebruik een dedicated search engine — **Elasticsearch/OpenSearch, gebouwd op een inverted index** — gevoed vanuit je bron-DB via **CDC**, en shard de index voor schaal. Je primaire database (Postgres/MySQL) kan geen relevantie-gerangschikte tekstsearch over honderden miljoenen rows; een `LIKE '%term%'` scant elke row. Een search engine keert het probleem om.

```text
Bron-DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)  (change stream)                       ├─ Shard 0 (inverted index) + replica's
                                                    ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter naar shards ─▶ gather ─┴─ Shard N ── gerangschikt op BM25
```

## Inverted index — waarom het snel is

Een normale index mapt row → waarden. Een **inverted index** mapt *term → lijst van documenten die hem bevatten*. Zoeken naar "database scaling" zoekt twee korte posting lists op en snijdt ze — O(matchende docs), niet O(alle docs). Dit maakt sub-100ms search over 100M+ documenten mogelijk. Tekst wordt eerst **geanalyseerd**: getokeniseerd, lowercased, gestemd ("running" → "run"), stopwords gedropt — zodat queries varianten matchen.

## Ingestie via CDC

Dual-write niet (app schrijft naar DB *en* ES) — een fout laat ze inconsistent achter. Stream in plaats daarvan wijzigingen met **Change Data Capture**: **Debezium** tailt de write-ahead log van de DB, publiceert row-wijzigingen naar **Kafka**, en een indexer past ze toe op Elasticsearch. Dit houdt search **eventually consistent** met de bron en overleeft ES-downtime (events replayen vanuit Kafka).

## Sharding & relevantie

De index wordt gesplitst in **shards** (elk een op zichzelf staande Lucene-index), verspreid over nodes; **replica's** voegen read-throughput en HA toe. Een query scatteret naar alle shards, elk geeft zijn top-k terug, en de coordinator merget. Relevantie gebruikt standaard **BM25** — term frequency × inverse document frequency — afstembaar met boosts, synoniemen en veldgewichten.

## Interviewperspectief

Interviewers checken of je (1) grijpt naar het juiste gereedschap in plaats van `LIKE`, (2) weet *hoe* de inverted index werkt, en (3) het **sync-probleem** oplost zonder dual-writes. Goed: "gebruik Elasticsearch." Uitstekend: je benoemt CDC/Debezium voor ingestie, BM25 voor ranking, en accepteert eventual consistency als de afweging voor schaal.

**Veelvoorkomende valkuil:** Elasticsearch als je source of truth behandelen. Het is een afgeleide index — niet duurzaam/transactioneel zoals je DB. Herbouw het uit de bron wanneer nodig.

## Afwegingen & faalmodi

- **Eventual consistency:** search loopt achter op writes met de CDC-pipeline-latency (meestal sub-seconde).
- **Reindex-pijn:** mapping/analyzer-wijzigingen vereisen een volledige reindex — gebruik aliassen voor zero-downtime swaps.
- **Diepe paginatie:** pagina 10.000 is duur (scatter-gather) — gebruik `search_after`, niet `from/size`.
- **Hot shard / skew:** ongelijke doc-distributie; kies een goede routing key en genoeg shards vooraf (ze staan vast bij aanmaak).
- **Relevantie-tuning is doorlopend:** BM25-defaults matchen zelden de business-intentie — verwacht iteratie.

Inverted index — waarom het snel is

Ingestie via CDC

Sharding & relevantie

Interviewperspectief

Afwegingen & faalmodi

Gerelateerde vragen