నిమిషానికి millions of req వద్ద DB load ను తగ్గించడానికి మీరు ఎలా cache చేస్తారు?

Question

IT Interview Practice · Accepted Answer

DB ముందు ఒక **cache-aside** layer (Redis/Memcached) ను ఉంచండి తద్వారా reads memory ను తాకుతాయి, entries కి ఒక **TTL** ఇచ్చి **write పై invalidate** చేయండి, ఒక cold key DB పై ఒక thundering herd ను విడుదల చేయలేకుండా **stampede protection** ను జోడించండి, మరియు ఒక popular key ఒక్క node ను కరిగించకుండా **hot keys** ను replicas అంతటా విస్తరించండి.

```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 ను read చేసి cache ను తానే populate చేస్తుంది. **read-through** లో cache library దాన్ని మీ కోసం చేస్తుంది. ఏ విధంగానైనా లక్ష్యం ఒకటే: ఒక 5ms DB query ను ఒక 0.2ms memory lookup గా మార్చడం, తద్వారా 95% hit rate ఉన్న ఒక cache DB read traffic ను **20×** తగ్గిస్తుంది. నిమిషానికి millions of req వద్ద DB ప్రతి read ను serve చేయలేదు — cache అనేదే సంఖ్యలను పనిచేయిస్తుంది.

## TTL + invalidation

cache ను fresh గా ఉంచడానికి రెండు మార్గాలు, మరియు మీకు సాధారణంగా రెండూ అవసరం. **TTL** staleness ను bound చేస్తుంది — ఒక entry N seconds తర్వాత expire అవుతుంది కాబట్టి తప్పు data self-heal అవుతుంది. **Explicit invalidation** TTL కి వేచి ఉండలేని correctness కోసం write పై key ను delete/update చేస్తుంది. Classic bug invalidation లేకుండా cache చేసి నిమిషాల పాటు 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** తో fix చేయండి.
- **Hot keys:** ఒక key (ఒక celebrity యొక్క profile) ఒక్క Redis node యొక్క CPU/network ను saturate చేయవచ్చు. దాన్ని విస్తరించండి — key ను nodes అంతటా replicate చేయండి, లేదా hottest items కోసం Redis ముందు ఒక చిన్న local in-process cache జోడించండి.

## ఇంటర్వ్యూ దృక్కోణం

ఇంటర్వ్యూయర్ మీరు "add Redis" కి మించి ఆలోచించడం చూడాలనుకుంటారు. మంచిది: TTL తో cache-aside. గొప్పది: మీరు **stampede protection, invalidation strategy, hot-key handling, మరియు cache outage పై ఏమి జరుగుతుందో** పేర్కొంటారు. ఉచ్చు cache ఎల్లప్పుడూ up అని భావించడం — Redis చనిపోయి ప్రతి miss DB కి fall through అయితే, మీరు DB ను కూడా down చేసే ఒక **cache-avalanche** ను పొందుతారు.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **Staleness vs load:** short TTL = fresh కానీ ఎక్కువ misses; long TTL = తక్కువ misses కానీ staler. ఒక్కో data కి tune చేయండి.
- **Cache avalanche:** అనేక keys కలిసి expire అవ్వడం (same TTL) ఒక load spike కలిగిస్తుంది — TTLs ను **jitter** చేయండి.
- **Consistency:** cache మరియు DB diverge కావచ్చు; money-critical reads కి, DB ను read చేయండి లేదా 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

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు