Kif tikkaċċja biex tnaqqas il-load tad-DB b'miljuni ta' req/min?

Question

IT Interview Practice · Accepted Answer

Poġġi layer **cache-aside** (Redis/Memcached) quddiem id-DB biex ir-reads jolqtu l-memorja, agħti lill-entrati **TTL** u **invalida fuq write**, żid **stampede protection** biex key kiesaħ ma jkunx jista' jerħi thundering herd fuq id-DB, u ifrex **hot keys** fuq ir-replicas biex key popolari wieħed ma jinħallx node wieħed.

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

F'**cache-aside** l-app tiċċekkja l-cache; fuq miss taqra d-DB u timla l-cache hija stess. F'**read-through** il-cache library tagħmel dan għalik. F'kull każ l-għan huwa l-istess: ibdel query tad-DB ta' 5ms f'memory lookup ta' 0.2ms, biex cache b'hit rate ta' 95% jnaqqas it-traffiku tar-reads tad-DB **20×**. B'miljuni ta' req/min id-DB sempliċiment ma jistax iservi kull read — il-cache hu li jagħmel in-numri jaħdmu.

## TTL + invalidation

Żewġ modi biex iżżomm il-cache frisk, u normalment għandek bżonn it-tnejn. **TTL** jillimita l-istaleness — entrata tiskadi wara N sekonda biex data ħażina tfejjaq lilha nnifisha. **Invalidation espliċita** tħassar/taġġorna l-key fuq write għal korrettezza li ma tistax tistenna t-TTL. Il-bug klassiku huwa caching mingħajr invalidation u tservi data staljata għal minuti; is-suttili huwa li tinvalida *u* tissettja fl-istess write, li joħloq race.

## Stampede protection u hot keys

- **Stampede (thundering herd):** meta key jaħraq jiskadi, eluf ta' misses konkorrenti jolqtu d-DB f'daqqa u jistgħu jwaqqgħuh. Aġġusta b'**per-key lock/single-flight** (talba waħda tikkalkula mill-ġdid, l-oħrajn jistennew) jew **early/probabilistic refresh** qabel l-iskadenza.
- **Hot keys:** key wieħed (profil ta' ċelebrità) jista' jissatura s-CPU/network ta' node wieħed ta' Redis. Ifirxu — irreplika l-key fuq nodes, jew żid local in-process cache żgħir quddiem Redis għall-aktar items jaħarqu.

## Perspettiva tal-intervista

L-intervistatur irid jarak taħseb lil hinn minn "żid Redis". Tajjeb: cache-aside b'TTL. Eċċellenti: issemmi **stampede protection, strateġija ta' invalidation, hot-key handling, u x'jiġri fuq cache outage**. In-nassa hija li tassumi li l-cache dejjem hija up — jekk Redis imut u kull miss jaqa' għad-DB, tikseb **cache-avalanche** li tieħu d-DB miegħu wkoll.

## Trade-offs u modi ta' fallimenti

- **Staleness vs load:** TTL qasir = frisk imma aktar misses; TTL twil = inqas misses imma aktar staljat. Aġġusta għal kull data.
- **Cache avalanche:** ħafna keys jiskadu flimkien (l-istess TTL) jikkawżaw spike ta' load — agħmel **jitter** tat-TTLs.
- **Konsistenza:** il-cache u d-DB jistgħu jiddevjaw; għal reads kritiċi tal-flus, aqra d-DB jew uża write-through.
- **Memory eviction:** taħt pressjoni Redis jagħmel evict skont policy (LRU/LFU); policy ħażina siekta twaqqa' l-hot set tiegħek.

Cache-aside vs read-through

TTL + invalidation

Stampede protection u hot keys

Perspettiva tal-intervista

Trade-offs u modi ta' fallimenti

Mistoqsijiet relatati