लाखों req/min पर DB load काटने के लिए आप कैसे cache करते हैं?

Question

IT Interview Practice · Accepted Answer

DB के सामने एक **cache-aside** layer (Redis/Memcached) रखें ताकि reads memory पर लगें, entries को एक **TTL** दें और **write पर invalidate करें**, **stampede protection** जोड़ें ताकि एक cold key DB पर एक thundering herd न छोड़े, और **hot keys** को replicas में फैलाएं ताकि एक popular key एक अकेले node को न पिघलाए।

```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 बनाम read-through

**cache-aside** में app cache चेक करता है; एक miss पर यह DB पढ़ता है और खुद cache populate करता है। **read-through** में cache library यह आपके लिए करती है। किसी भी तरह लक्ष्य समान है: एक 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 को ताज़ा रखने के दो तरीके, और आपको आमतौर पर दोनों चाहिए। **TTL** staleness को सीमित करता है — एक entry N सेकंड बाद expire होती है ताकि गलत data self-heal हो। **Explicit invalidation** correctness के लिए write पर key delete/update करता है जो TTL का इंतज़ार नहीं कर सकता। क्लासिक bug है invalidation के बिना cache करना और minutes तक stale data serve करना; सूक्ष्म वाला है एक ही write में invalidate *और* set करना, जो race करता है।

## Stampede protection और hot keys

- **Stampede (thundering herd):** जब एक hot key expire होती है, हज़ारों concurrent misses सब एक साथ DB पर लगते हैं और उसे गिरा सकते हैं। एक **per-key lock/single-flight** (केवल एक request recompute करती है, बाकी इंतज़ार करती हैं) या expiry से पहले **early/probabilistic refresh** से ठीक करें।
- **Hot keys:** एक key (एक celebrity की profile) एक अकेले Redis node के CPU/network को saturate कर सकती है। इसे फैलाएं — key को nodes में replicate करें, या सबसे hot items के लिए Redis के सामने एक छोटा local in-process cache जोड़ें।

## इंटरव्यू का नज़रिया

Interviewer आपको "Redis जोड़ें" से आगे सोचते देखना चाहता है। अच्छा: TTL के साथ cache-aside। बढ़िया: आप **stampede protection, invalidation strategy, hot-key handling, और cache outage पर क्या होता है** नाम लेते हैं। जाल है यह मानना कि cache हमेशा up है — अगर Redis मर जाए और हर miss DB तक गिरे, आपको एक **cache-avalanche** मिलता है जो DB को भी नीचे ले जाता है।

## ट्रेड-ऑफ़ और failure modes

- **Staleness बनाम load:** छोटा TTL = ताज़ा पर अधिक 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:** दबाव में Redis policy से evict करता है (LRU/LFU); एक गलत policy चुपचाप आपके hot set को गिरा देती है।

Cache-aside बनाम read-through

TTL + invalidation

Stampede protection और hot keys

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न