Kepiye sampeyan cache kanggo ngurangi beban DB ing jutaan req/menit?

Question

IT Interview Practice · Accepted Answer

Selehke lapisan **cache-aside** (Redis/Memcached) ing ngarep DB supaya pamaca ndemek memori, wenehi entri **TTL** lan **invalidasi nalika nulis**, tambahake **proteksi stampede** supaya cold key ora bisa nglepasake thundering herd menyang DB, lan sebar **hot key** ing pirang-pirang replika supaya siji key sing populer ora ngleburake siji 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

Ing **cache-aside** app mriksa cache; nalika miss iku maca DB lan ngisi cache dhewe. Ing **read-through** pustaka cache sing nglakoni kanggo sampeyan. Loro-lorone tujuane padha: ngowahi query DB 5ms dadi lookup memori 0.2ms, mula cache kanthi hit rate 95% ngurangi lalu lintas maca DB **20×**. Ing jutaan req/menit DB pancen ora bisa ngladeni saben pamaca — cache sing ndadekake angkane mlaku.

## TTL + invalidasi

Loro cara kanggo njaga cache tetep seger, lan biasane sampeyan butuh loro-lorone. **TTL** mbatesi basi — sawijining entri kadaluwarsa sawise N detik supaya data salah nambani awake dhewe. **Invalidasi eksplisit** mbusak/nge-update key nalika nulis kanggo bener sing ora bisa ngenteni TTL. Bug klasik yaiku caching tanpa invalidasi lan ngladeni data basi pirang-pirang menit; sing luwih alus yaiku invalidasi *lan* nyetel ing tulisan sing padha, sing balapan.

## Proteksi stampede & hot key

- **Stampede (thundering herd):** nalika hot key kadaluwarsa, ewonan miss bebarengan kabeh ndemek DB sanalika lan bisa njungkelake. Ndandani nganggo **lock/single-flight saben-key** (mung siji request ngitung maneh, liyane ngenteni) utawa **refresh awal/probabilistik** sadurunge kadaluwarsa.
- **Hot key:** siji key (profil selebriti) bisa njenuhi CPU/jaringan siji node Redis. Sebar — replikasi key ing pirang-pirang node, utawa tambahake cache in-process lokal cilik ing ngarep Redis kanggo item sing paling panas.

## Sudut pandang wawancara

Pewawancara pengin ndeleng sampeyan mikir ngluwihi "tambah Redis". Apik: cache-aside kanthi TTL. Apik banget: sampeyan nyebutake **proteksi stampede, strategi invalidasi, penanganan hot-key, lan apa sing kedadeyan nalika cache mati**. Jebakane yaiku nganggep cache tansah urip — yen Redis mati lan saben miss tiba menyang DB, sampeyan entuk **cache-avalanche** sing njungkelake DB uga.

## Trade-off & mode kegagalan

- **Basi vs beban:** TTL cendhak = seger nanging luwih akeh miss; TTL dawa = luwih sithik miss nanging luwih basi. Setel saben data.
- **Cache avalanche:** akeh key kadaluwarsa bareng (TTL padha) nyebabake lonjakan beban — **jitter** TTL-e.
- **Konsistensi:** cache lan DB bisa nyimpang; kanggo pamaca kritis dhuwit, maca DB utawa nganggo write-through.
- **Eviksi memori:** ing tekanan Redis nge-eviksi miturut kebijakan (LRU/LFU); kebijakan sing salah kanthi sepi mbuwang hot set sampeyan.

Cache-aside vs read-through

TTL + invalidasi

Proteksi stampede & hot key

Sudut pandang wawancara

Trade-off & mode kegagalan

Pitakon sing gegandhengan