Kepiye sampeyan mbangun full-text search marang 100 yuta+ record?

Question

IT Interview Practice · Accepted Answer

Nganggo mesin panelusuran khusus — **Elasticsearch/OpenSearch sing dibangun ing inverted index** — sing diwenehi saka DB sumber liwat **CDC**, lan shard indekse kanggo skala. Database utama sampeyan (Postgres/MySQL) ora bisa nindakake panelusuran teks sing di-rangking relevansi marang atusan yuta row; `LIKE '%term%'` nge-scan saben row. Mesin panelusuran mbalikake masalahe.

```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
```

## Inverted index — kenapa cepet

Indeks normal ngepetakan row → nilai. **Inverted index** ngepetakan *term → dhaptar dokumen sing ngandhut term kuwi*. Nggoleki "database scaling" nyleweki loro posting list sing cendhak lan ngiris (intersect) — O(dokumen sing cocog), dudu O(kabeh dokumen). Iki sing ndadekake panelusuran sangisore 100ms marang 100 yuta+ dokumen bisa. Teks di-**analisis** dhisik: di-tokenisasi, di-lowercase, di-stem ("running" → "run"), stopword dibuwang — supaya query cocog karo varian.

## Ingesti liwat CDC

Aja dual-write (app nulis DB *lan* ES) — kegagalan ninggalake loro ora konsisten. Malah, aliran owah-owahan nganggo **Change Data Capture**: **Debezium** ngetutake write-ahead log DB, ngpublikasi owah-owahan row menyang **Kafka**, lan sawijining indexer nrapake menyang Elasticsearch. Iki njaga panelusuran **eventually consistent** karo sumber lan slamet nalika ES mati (event replay saka Kafka).

## Sharding & relevansi

Indeks dipisah dadi **shard** (saben minangka indeks Lucene mandiri), disebar ing pirang-pirang node; **replika** nambah throughput pamaca lan HA. Query nyebar menyang kabeh shard, saben mbalekake top-k-ne, lan koordinator nggabung. Relevansi nganggo **BM25** minangka standar — frekuensi term × inverse document frequency — bisa diatur karo boost, sinonim, lan bobot field.

## Sudut pandang wawancara

Pewawancara mriksa apa sampeyan (1) njangkau alat sing bener tinimbang `LIKE`, (2) ngerti *kepiye* inverted index nyambut gawe, lan (3) ngrampungake **masalah sinkronisasi** tanpa dual-write. Apik: "nganggo Elasticsearch." Apik banget: sampeyan nyebutake CDC/Debezium kanggo ingesti, BM25 kanggo ranking, lan nampa eventual consistency minangka trade kanggo skala.

**Jebakan umum:** nganggep Elasticsearch minangka sumber kebeneran sampeyan. Iku indeks turunan — ora tahan lama/transaksional kaya DB sampeyan. Bangun maneh saka sumber nalika perlu.

## Trade-off lan mode kegagalan

- **Eventual consistency:** panelusuran keri saka tulisan miturut latency pipeline CDC (biasane sangisore detik).
- **Reindex sing lara:** owah-owahan mapping/analyzer butuh reindex lengkap — nganggo alias kanggo swap tanpa downtime.
- **Deep pagination:** kaca 10.000 iku larang (scatter-gather) — nganggo `search_after`, dudu `from/size`.
- **Hot shard / skew:** distribusi dokumen ora rata; pilih routing key sing apik lan shard sing cukup ing ngarep (dikunci nalika digawe).
- **Tuning relevansi terus-terusan:** standar BM25 arang cocog karo maksud bisnis — mesthi butuh iterasi.

Inverted index — kenapa cepet

Ingesti liwat CDC

Sharding & relevansi

Sudut pandang wawancara

Trade-off lan mode kegagalan

Pitakon sing gegandhengan