Apa distributed cache lan kepiye nangani kegagalane?

Question

IT Interview Practice · Accepted Answer

**Cache terdistribusi ngidini sawetara instance aplikasi nggunakake data maneh liwat jaringan.** Tujuane nyingkiri gaweyan larang sing dibaleni, kanthi aturan cetha babagan kesegaran lan kegagalan.

Bayangna telung instance backend maca katalog produk padha. Yen cache ana ing saben proses, saben instance njaga salinan dhewe. Yen layanan cache dienggo bebarengan, siji instance bisa ngisi nilai sing digunakake liyane. Layanan cache dhewe bisa nganggo sawetara node.

## 1. Temtokake apa sing aman di-cache

Wiwiti saka biaya ngasilake data lan sepira lawas sing isih diidini. Deskripsi produk bisa nampa tundha cekak; mriksa stok pungkasan nalika tuku bisa mbutuhake sumber resmi.

Gawe key sing ngenali asil lengkap, kalebu tenant, basa, lan input penting liyane. Yen ora, cache cepet bisa mbalekake data pelanggan sing salah. Database tetep dadi sumber resmi record bisnis awet, amarga nilai cache bisa ilang.

## 2. Tindakake alur maca sadurunge ngrancang pembaruan

Cara umum yaiku cache-aside: aplikasi mriksa cache, maca database yen ora ketemu, banjur nyimpen asil kanthi wektu kadaluwarsa, diarani TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Iki nyuda wacan database bola-bali yen akeh request butuh nilai padha. Nanging nambah panggilan jaringan lan dependensi, mula migunani yen gaweyan sing diirit ngluwihi biaya kasebut. Delengen [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Temtokake carane pembaruan katon

Kanggo katalog, wiwitan praktis yaiku commit pembaruan database banjur invalidasi produk ing cache. Pamaca sabanjure njupuk maneh. Nanging isih ana race: pamaca bisa njupuk nilai lawas sadurunge commit, banjur nglebokake ing cache sawise invalidasi.

TTL matesi suwene salinan anyar ing cache iku urip; ora njamin saben wacan langsung ndeleng panulisan paling anyar. Yen ijin, rega, utawa saldo lawas nglanggar aturan operasi, validasi marang sumber resmi utawa rancang pembaruan sing ngerti versi kanthi jaminan cetha. Pilih konsistensi miturut operasi bisnis, aja nganggep Redis otomatis ngrampungake.

## 4. Aja nganti cache miss dadi gangguan layanan

Yen entri populer kadaluwarsa, akeh pemanggil bisa maca database bebarengan. Iki cache stampede. Cache mati bisa nggawe masalah padha ing akeh entri.

- Gabungake loading bebarengan kanggo key padha supaya luwih sithik sing mbangun ulang; temtokake apa koordinasi mung siji proses utawa kabeh instance.
- Bedakake wektu kadaluwarsa supaya akeh entri ora entek bareng. Iki nyebar gaweyan refresh nanging ora ngrampungake kabeh masalah hot key.
- Gunakake nilai sadurunge nalika refresh mung yen bisnis ngidini data lawas.
- Gunakake timeout cache cekak lan matesi trafik fallback database. Nolak sawetara gaweyan bisa luwih aman tinimbang nggawe database kewalahan lan kabeh request gagal.

Uji alur kasebut kanthi sengaja. Hit rate dhuwur nalika normal ora akeh nerangake prilaku nalika cache ilang.

## 5. Tambah kapasitas miturut hambatan nyata

Sharding mbagi key antarane node cache; replikasi njaga salinan kanggo kasedhiyan utawa wacan. Loro-lorone ngrampungake masalah beda. Redis Cluster nganggo hash slot, mula nambah node ora otomatis mbagi gaweyan siji hot key. Delengen [spesifikasi Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Pantau hit rate, latensi, timeout, memori, eviction, lan beban menyang database. Eviction tegese cache mbusak nilai kanggo ngatur memori lan bisa kelakon sadurunge TTL entek. Aja nganggep entri cache minangka panyimpenan awet sing dijamin kanggo data bisnis utawa gaweyan antrean.

Kanggo katalog, aku bakal miwiti cache-aside kanthi key cetha, kabijakan kesegaran, lan fallback sing dilindhungi. Node anyar mung ditambah yen pangukuran nuduhake masalah kapasitas sing tenan bisa dirampungake distribusi. **Desain cache apik nerangake apa sing kelakon nalika nilai ana lan nalika ora ana utawa salah.**

1. Temtokake apa sing aman di-cache

2. Tindakake alur maca sadurunge ngrancang pembaruan

3. Temtokake carane pembaruan katon

4. Aja nganti cache miss dadi gangguan layanan

5. Tambah kapasitas miturut hambatan nyata

Pitakon sing gegandhengan