Bagaimana Anda melakukan caching untuk memangkas beban DB pada jutaan req/menit?

Question

IT Interview Practice · Accepted Answer

Taruh lapisan **cache-aside** (Redis/Memcached) di depan DB agar baca mengenai memori, beri entri **TTL** dan **invalidasi saat write**, tambahkan **proteksi stampede** agar cold key tidak melepaskan thundering herd ke DB, dan sebar **hot key** ke replica agar satu key populer tidak melelehkan satu node.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

Dalam **cache-aside** app memeriksa cache; saat miss ia membaca DB dan mengisi cache sendiri. Dalam **read-through** library cache melakukannya untuk Anda. Bagaimanapun tujuannya sama: mengubah query DB 5ms menjadi lookup memori 0,2ms, sehingga cache dengan hit rate 95% memangkas trafik baca DB **20×**. Pada jutaan req/menit DB sekadar tidak bisa melayani setiap baca — cache-lah yang membuat angkanya masuk akal.

## TTL + invalidasi

Dua cara menjaga cache tetap segar, dan Anda biasanya butuh keduanya. **TTL** membatasi kebasian — sebuah entri kedaluwarsa setelah N detik sehingga data salah menyembuhkan diri. **Invalidasi eksplisit** menghapus/meng-update key saat write untuk correctness yang tidak bisa menunggu TTL. Bug klasik adalah caching tanpa invalidasi dan menyajikan data basi selama beberapa menit; yang lebih halus adalah invalidasi *dan* set dalam write yang sama, yang balapan (race).

## Proteksi stampede & hot key

- **Stampede (thundering herd):** ketika hot key kedaluwarsa, ribuan miss bersamaan semua mengenai DB sekaligus dan bisa menumbangkannya. Perbaiki dengan **per-key lock/single-flight** (hanya satu request menghitung ulang, yang lain menunggu) atau **early/probabilistic refresh** sebelum kedaluwarsa.
- **Hot key:** satu key (profil selebritas) bisa menjenuhkan CPU/jaringan satu node Redis. Sebar — replikasi key ke banyak node, atau tambahkan cache in-process lokal kecil di depan Redis untuk item terpanas.

## Perspektif wawancara

Pewawancara ingin melihat Anda berpikir melampaui "tambah Redis". Baik: cache-aside dengan TTL. Hebat: Anda menyebut **proteksi stampede, strategi invalidasi, penanganan hot-key, dan apa yang terjadi saat padamnya cache**. Jebakannya adalah mengasumsikan cache selalu up — jika Redis mati dan setiap miss jatuh ke DB, Anda mendapat **cache-avalanche** yang menumbangkan DB juga.

## Trade-off & mode kegagalan

- **Kebasian vs beban:** TTL pendek = segar tetapi lebih banyak miss; TTL panjang = lebih sedikit miss tetapi lebih basi. Tune per data.
- **Cache avalanche:** banyak key kedaluwarsa bersamaan (TTL sama) menyebabkan lonjakan beban — beri **jitter** pada TTL.
- **Consistency:** cache dan DB bisa berdivergensi; untuk baca kritis-uang, baca DB atau gunakan write-through.
- **Eviksi memori:** di bawah tekanan Redis meng-evict berdasarkan policy (LRU/LFU); policy yang salah diam-diam membuang hot set Anda.

Cache-aside vs read-through

TTL + invalidasi

Proteksi stampede & hot key

Perspektif wawancara

Trade-off & mode kegagalan

Pertanyaan terkait