Ta yaya za ka cache don rage DB load a miliyoyin req/min?

Question

IT Interview Practice · Accepted Answer

Sanya **cache-aside** layer (Redis/Memcached) a gaban DB domin reads su bugi memory, ba entries **TTL** kuma ka **invalidate a write**, ka ƙara **stampede protection** domin cold key kada ya kori thundering herd a DB, kuma ka baza **hot keys** a kan replicas domin popular key ɗaya kada ya narke node ɗaya.

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

A **cache-aside** app yana bincika cache; a miss yana karanta DB kuma yana populate cache da kansa. A **read-through** cache library yana yin hakan gare ka. Ta kowace hanya manufa iri ɗaya ce: mai da 5ms DB query zuwa 0.2ms memory lookup, domin cache da 95% hit rate yana rage DB read traffic **20×**. A miliyoyin req/min DB kawai ba zai iya bauta kowane read ba — cache shi ne abin da ke sa lambobi su yi aiki.

## TTL + invalidation

Hanyoyi biyu na ajiye cache fresh, kuma yawanci kana buƙatar duka. **TTL** yana iyakance staleness — entry yana ƙarewa bayan daƙiƙu N don wrong data ya warkar da kansa. **Explicit invalidation** yana share/update key a write don daidaito da ba zai iya jira TTL ba. Bug na gargajiya shi ne caching ba tare da invalidation ba kuma ka bauta stale data na mintuna; mai dabara shi ne invalidating *da* setting a same write, wanda ke race.

## Stampede protection & hot keys

- **Stampede (thundering herd):** lokacin da hot key ya ƙare, dubban concurrent misses duk suna bugun DB a lokaci ɗaya kuma na iya kifar da shi. Gyara da **per-key lock/single-flight** (request ɗaya kawai ke recompute, sauran suna jira) ko **early/probabilistic refresh** kafin expiry.
- **Hot keys:** key ɗaya (profile na celebrity) na iya cika CPU/network na Redis node ɗaya. Baza shi — replicate key a kan nodes, ko ƙara ƙaramin local in-process cache a gaban Redis ga mafi hottest items.

## Ra'ayin hira

Mai yin hirar yana son ganin ka yi tunani fiye da "ƙara Redis". Mai kyau: cache-aside da TTL. Mai kyau sosai: ka ambaci **stampede protection, invalidation strategy, hot-key handling, da abin da ke faruwa a cache outage**. Tarko shi ne ɗaukar cache koyaushe yana sama — idan Redis ya mutu kuma kowane miss ya faɗa DB, kana samun **cache-avalanche** da ke saukar da DB ma.

## Sulhu & hanyoyin gazawa

- **Staleness vs load:** short TTL = fresh amma misses masu yawa; long TTL = ƙananan misses amma staler. Tune ga kowace data.
- **Cache avalanche:** keys da yawa suna expiring tare (same TTL) yana haifar da load spike — **jitter** TTLs.
- **Consistency:** cache da DB na iya kauda; ga money-critical reads, karanta DB ko yi amfani da write-through.
- **Memory eviction:** a ƙarƙashin matsi Redis yana evict da policy (LRU/LFU); policy mara kyau yana zubar da hot set ɗinka a shiru.

Cache-aside vs read-through

TTL + invalidation

Stampede protection & hot keys

Ra'ayin hira

Sulhu & hanyoyin gazawa

Tambayoyi masu alaƙa