Bagaimana Anda membangun full-text search atas 100 juta+ record?

Question

IT Interview Practice · Accepted Answer

Gunakan search engine khusus — **Elasticsearch/OpenSearch yang dibangun di atas inverted index** — yang diberi makan dari DB sumber Anda via **CDC**, dan shard index-nya untuk skala. Database primer Anda (Postgres/MySQL) tidak bisa melakukan pencarian teks berperingkat relevansi atas ratusan juta baris; sebuah `LIKE '%term%'` men-scan setiap baris. Search engine membalik masalahnya.

```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 — mengapa cepat

Sebuah index normal memetakan baris → nilai. Sebuah **inverted index** memetakan *term → daftar dokumen yang memuatnya*. Mencari "database scaling" melihat dua posting list pendek dan meng-intersect-nya — O(matching docs), bukan O(all docs). Inilah yang membuat pencarian sub-100ms atas 100 juta+ dokumen menjadi mungkin. Teks **dianalisis** dulu: di-tokenisasi, di-lowercase, di-stem ("running" → "run"), stopword dibuang — sehingga query mencocokkan varian.

## Ingesti via CDC

Jangan dual-write (app menulis DB *dan* ES) — sebuah kegagalan meninggalkan keduanya tidak konsisten. Alih-alih, stream perubahan dengan **Change Data Capture**: **Debezium** menelusuri write-ahead log DB, mempublikasikan perubahan baris ke **Kafka**, dan sebuah indexer menerapkannya ke Elasticsearch. Ini menjaga pencarian **eventually consistent** dengan sumber dan bertahan dari padamnya ES (event replay dari Kafka).

## Sharding & relevansi

Index dipecah menjadi **shard** (masing-masing Lucene index mandiri), tersebar antar-node; **replica** menambah throughput baca dan HA. Sebuah query scatter ke semua shard, masing-masing mengembalikan top-k-nya, dan coordinator me-merge. Relevansi menggunakan **BM25** secara default — term frequency × inverse document frequency — dapat di-tune dengan boost, sinonim, dan bobot field.

## Perspektif wawancara

Pewawancara memeriksa apakah Anda (1) meraih alat yang tepat alih-alih `LIKE`, (2) tahu *bagaimana* inverted index bekerja, dan (3) menyelesaikan **masalah sinkronisasi** tanpa dual-write. Baik: "gunakan Elasticsearch." Hebat: Anda menyebut CDC/Debezium untuk ingesti, BM25 untuk peringkat, dan menerima eventual consistency sebagai trade-off untuk skala.

**Jebakan umum:** memperlakukan Elasticsearch sebagai sumber kebenaran Anda. Ia adalah index turunan — tidak durable/transaksional seperti DB Anda. Bangun ulang dari sumber saat dibutuhkan.

## Trade-off & mode kegagalan

- **Eventual consistency:** pencarian tertinggal write sebesar latensi pipeline CDC (biasanya sub-detik).
- **Nyeri reindex:** perubahan mapping/analyzer butuh reindex penuh — gunakan alias untuk swap zero-downtime.
- **Deep pagination:** halaman 10.000 mahal (scatter-gather) — gunakan `search_after`, bukan `from/size`.
- **Shard panas / skew:** distribusi dokumen tidak merata; pilih routing key yang baik dan cukup shard di awal (jumlahnya tetap saat pembuatan).
- **Tuning relevansi berkelanjutan:** default BM25 jarang cocok dengan intent bisnis — harapkan iterasi.

Inverted index — mengapa cepat

Ingesti via CDC

Sharding & relevansi

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait