લાખો req/min પર DB load ઘટાડવા તમે કેવી રીતે cache કરશો?

Question

IT Interview Practice · Accepted Answer

DB ની આગળ એક **cache-aside** layer (Redis/Memcached) મૂકો જેથી reads memory પર hit કરે, entries ને **TTL** આપો અને **write પર invalidate** કરો, **stampede protection** ઉમેરો જેથી cold key DB પર thundering herd ન છોડે, અને **hot keys** ને replicas પર ફેલાવો જેથી એક popular key એક node ને melt ન કરે.

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

**cache-aside** માં app cache check કરે છે; miss પર તે DB વાંચે છે અને cache ને પોતે populate કરે છે. **read-through** માં cache library તે તમારા માટે કરે છે. કોઈપણ રીતે goal એ જ છે: 5ms DB query ને 0.2ms memory lookup માં ફેરવવું, જેથી 95% hit rate વાળું cache DB read traffic **20×** ઘટાડે. લાખો req/min પર DB દરેક read serve કરી શકતું જ નથી — cache એ છે જે numbers ને કામ કરાવે છે.

## TTL + invalidation

cache fresh રાખવાની બે રીતો, અને તમને સામાન્ય રીતે બંને જોઈએ. **TTL** staleness ને bound કરે છે — entry N seconds પછી expire થાય જેથી ખોટો data self-heal થાય. **Explicit invalidation** correctness માટે write પર key delete/update કરે છે જે TTL ની રાહ ન જોઈ શકે. Classic bug એ invalidation વગર cache કરવો અને મિનિટો સુધી stale data serve કરવો; સૂક્ષ્મ bug એ એ જ write માં invalidate *અને* set કરવો, જે race કરે છે.

## Stampede protection & hot keys

- **Stampede (thundering herd):** જ્યારે hot key expire થાય, હજારો concurrent misses બધા એકસાથે DB પર hit કરે અને તેને પાડી શકે. **per-key lock/single-flight** (માત્ર એક request recompute કરે, બાકી રાહ જુએ) અથવા expiry પહેલાં **early/probabilistic refresh** વડે ઠીક કરો.
- **Hot keys:** એક key (celebrity ની profile) એક Redis node ના CPU/network ને saturate કરી શકે. તેને ફેલાવો — key ને nodes પર replicate કરો, અથવા hottest items માટે Redis ની આગળ નાનું local in-process cache ઉમેરો.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર તમને "Redis ઉમેરો" થી આગળ વિચારતા જોવા માંગે છે. Good: TTL સાથે cache-aside. Great: તમે **stampede protection, invalidation strategy, hot-key handling, અને cache outage પર શું થાય** નું નામ આપો છો. Trap એ ધારવું કે cache હંમેશા up છે — જો Redis મરી જાય અને દરેક miss DB પર fall through થાય, તો તમને એક **cache-avalanche** મળે છે જે DB ને પણ down લઈ જાય છે.

## Trade-offs અને failure modes

- **Staleness vs load:** ટૂંકું TTL = fresh પણ વધુ misses; લાંબું TTL = ઓછા misses પણ staler. પ્રતિ data tune કરો.
- **Cache avalanche:** ઘણી keys એકસાથે expire થવી (એ જ TTL) load spike કરે — TTLs ને **jitter** કરો.
- **Consistency:** cache અને DB diverge થઈ શકે; money-critical reads માટે, DB વાંચો અથવા write-through વાપરો.
- **Memory eviction:** pressure હેઠળ Redis policy (LRU/LFU) વડે evict કરે છે; ખોટી policy ચૂપચાપ તમારો hot set drop કરે છે.

Cache-aside vs read-through

TTL + invalidation

Stampede protection & hot keys

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો