Si bëni cache për të prerë ngarkesën e DB në miliona req/min?

Question

IT Interview Practice · Accepted Answer

Vendosni një layer **cache-aside** (Redis/Memcached) përpara DB-së që leximet të godasin memorien, jepini hyrjeve një **TTL** dhe **invalidoni në shkrim**, shtoni **stampede protection** që një key i ftohtë të mos lëshojë një thundering herd mbi DB, dhe shpërndani **hot keys** nëpër replicas që një key i popullarizuar të mos shkrijë një node të vetëm.

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

Në **cache-aside** aplikacioni kontrollon cache-in; në një miss lexon DB-në dhe popullon vetë cache-in. Në **read-through** biblioteka e cache e bën atë për ju. Sido që të jetë qëllimi është i njëjtë: kthimi i një query DB 5ms në një memory lookup 0.2ms, kështu që një cache me 95% hit rate pret read traffic-un e DB **20×**. Në miliona req/min DB thjesht nuk mund të shërbejë çdo lexim — cache-i është ai që i bën numrat të funksionojnë.

## TTL + invalidation

Dy mënyra për ta mbajtur cache-in të freskët, dhe zakonisht ju duhen të dyja. **TTL** kufizon staleness — një hyrje skadon pas N sekondash që të dhënat e gabuara të vetë-shërohen. **Invalidation eksplicit** fshin/përditëson key-in në shkrim për korrektësi që nuk mund të presë TTL-në. Bug-u klasik është cache pa invalidation dhe shërbimi i të dhënave të vjetruara për minuta; ai më i hollë është invalidimi *dhe* set-imi në të njëjtin shkrim, që bën race.

## Stampede protection & hot keys

- **Stampede (thundering herd):** kur një key i nxehtë skadon, mijëra miss konkurrentë godasin DB-në njëkohësisht dhe mund ta rrëzojnë. Rregulloni me një **per-key lock/single-flight** (vetëm një request rillogarit, të tjerët presin) ose **refresh të hershëm/probabilistik** para skadimit.
- **Hot keys:** një key (profili i një celebriteti) mund të ngopë CPU-në/rrjetin e një node-i të vetëm Redis. Shpërndajeni — replikoni key-in nëpër node, ose shtoni një local in-process cache të vogël përpara Redis për artikujt më të nxehtë.

## Këndvështrimi i intervistës

Intervistuesi dëshiron t'ju shohë të mendoni përtej "shto Redis". Mirë: cache-aside me TTL. E shkëlqyer: emërtoni **stampede protection, strategjinë e invalidation, trajtimin e hot-key, dhe çfarë ndodh gjatë një ndërprerjeje cache**. Kurthi është supozimi se cache-i është gjithmonë lart — nëse Redis vdes dhe çdo miss bie te DB, merrni një **cache-avalanche** që rrëzon edhe DB-në.

## Kompromiset & mënyrat e dështimit

- **Staleness vs ngarkesa:** TTL i shkurtër = i freskët por më shumë miss; TTL i gjatë = më pak miss por më i vjetruar. Rregulloni sipas të dhënave.
- **Cache avalanche:** shumë keys që skadojnë bashkë (i njëjti TTL) shkakton një spike ngarkese — bëni **jitter** të TTL-ve.
- **Konsistenca:** cache dhe DB mund të divergojnë; për lexime kritike për paratë, lexoni DB-në ose përdorni write-through.
- **Memory eviction:** nën presion Redis bën evict sipas policy (LRU/LFU); një policy e gabuar heshturazi hedh hot set-in tuaj.

Cache-aside vs read-through

TTL + invalidation

Stampede protection & hot keys

Këndvështrimi i intervistës

Kompromiset & mënyrat e dështimit

Pyetje të ngjashme