Unacache vipi kupunguza DB load kwenye mamilioni ya req/min?

Question

IT Interview Practice · Accepted Answer

Weka layer ya **cache-aside** (Redis/Memcached) mbele ya DB ili reads zipige memory, zipe entries **TTL** na **invalidate kwenye write**, ongeza **stampede protection** ili cold key isiweze kuachilia thundering herd kwenye DB, na sambaza **hot keys** kwenye replicas ili key moja maarufu isiyeyushe node moja.

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

Katika **cache-aside** app hukagua cache; kwenye miss husoma DB na kujaza cache yenyewe. Katika **read-through** cache library hufanya hivyo kwa niaba yako. Kwa vyovyote lengo ni sawa: kubadilisha DB query ya 5ms kuwa memory lookup ya 0.2ms, hivyo cache yenye hit rate ya 95% hupunguza DB read traffic **mara 20**. Kwenye mamilioni ya req/min DB haiwezi kutumikia kila read — cache ndiyo hufanya namba zifanye kazi.

## TTL + invalidation

Njia mbili za kuweka cache fresh, na kwa kawaida unahitaji zote mbili. **TTL** huweka mipaka ya staleness — entry huisha baada ya sekunde N ili data isiyo sahihi ijiponye. **Explicit invalidation** hufuta/huupdate key kwenye write kwa usahihi usioweza kusubiri TTL. Bug ya kawaida ni ku-cache bila invalidation na kutumikia stale data kwa dakika; ya hila zaidi ni ku-invalidate *na* kuweka katika write ile ile, ambayo huraces.

## Stampede protection na hot keys

- **Stampede (thundering herd):** wakati hot key inaisha, maelfu ya misses za pamoja zote hupiga DB kwa mara moja na zinaweza kuiangusha. Rekebisha kwa **per-key lock/single-flight** (request moja tu huhesabu upya, nyingine husubiri) au **early/probabilistic refresh** kabla ya expiry.
- **Hot keys:** key moja (profile ya celebrity) inaweza kujaza CPU/network ya node moja ya Redis. Isambaze — replicate key kwenye nodes, au ongeza local in-process cache ndogo mbele ya Redis kwa items za moto zaidi.

## Mtazamo wa mahojiano

Mhojiwa anataka kukuona ukifikiri zaidi ya "ongeza Redis". Nzuri: cache-aside na TTL. Bora sana: unataja **stampede protection, invalidation strategy, hot-key handling, na kinachotokea kwenye cache outage**. Mtego ni kudhani cache ipo daima — ikiwa Redis itafa na kila miss huanguka hadi DB, unapata **cache-avalanche** inayoshusha DB pia.

## Maelewano na aina za hitilafu

- **Staleness vs load:** TTL fupi = fresh lakini misses zaidi; TTL ndefu = misses chache lakini staler. Tune kwa kila data.
- **Cache avalanche:** keys nyingi zinazoisha pamoja (TTL sawa) husababisha load spike — **jitter** TTLs.
- **Consistency:** cache na DB zinaweza kutofautiana; kwa money-critical reads, soma DB au tumia write-through.
- **Memory eviction:** chini ya shinikizo Redis huevict kwa policy (LRU/LFU); policy mbaya hudondosha hot set yako kimya.

Cache-aside vs read-through

TTL + invalidation

Stampede protection na hot keys

Mtazamo wa mahojiano

Maelewano na aina za hitilafu

Maswali yanayohusiana