لاکھوں 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 میں پھیلائیں تاکہ ایک مقبول 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 خود آباد کرتی ہے۔ **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 وہی ہے جو اعداد کو کام کرنے دیتا ہے۔

## TTL + invalidation

cache کو تازہ رکھنے کے دو طریقے، اور عموماً آپ کو دونوں چاہئیں۔ **TTL** staleness کو محدود کرتا ہے — ایک entry N سیکنڈ بعد expire ہوتی ہے تاکہ غلط ڈیٹا خود ٹھیک ہو جائے۔ **Explicit invalidation** درستگی کے لیے write پر key کو delete/update کرتا ہے جو TTL کا انتظار نہیں کر سکتی۔ کلاسک bug invalidation کے بغیر cache کرنا اور منٹوں تک stale ڈیٹا 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 دوبارہ compute کرتی ہے، باقی انتظار کرتی ہیں) یا expiry سے پہلے **early/probabilistic refresh** سے ٹھیک کریں۔
- **Hot keys:** ایک key (ایک celebrity کی profile) ایک واحد Redis node کا CPU/network saturate کر سکتی ہے۔ اسے پھیلائیں — key کو nodes میں replicate کریں، یا سب سے hot items کے لیے Redis کے آگے ایک چھوٹا local in-process cache شامل کریں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا دیکھنا چاہتا ہے کہ آپ "Redis شامل کرو" سے آگے سوچیں۔ اچھا: TTL کے ساتھ cache-aside۔ عمدہ: آپ **stampede protection، invalidation strategy، hot-key handling، اور cache outage پر کیا ہوتا ہے** کا نام لیتے ہیں۔ جال یہ فرض کرنا ہے کہ cache ہمیشہ up ہے — اگر Redis مر جائے اور ہر miss DB تک گر جائے، تو آپ کو ایک **cache-avalanche** ملتا ہے جو DB کو بھی نیچے لے جاتا ہے۔

## توازن اور ناکامی کے طریقے

- **Staleness بمقابلہ load:** مختصر TTL = تازہ مگر زیادہ misses؛ طویل TTL = کم misses مگر زیادہ stale۔ فی data tune کریں۔
- **Cache avalanche:** بہت سے keys کا ایک ساتھ expire ہونا (ایک ہی TTL) load spike پیدا کرتا ہے — TTLs میں **jitter** ڈالیں۔
- **مطابقت:** cache اور DB diverge کر سکتے ہیں؛ پیسے سے متعلق reads کے لیے، DB پڑھیں یا write-through استعمال کریں۔
- **Memory eviction:** دباؤ کے تحت Redis policy سے evict کرتا ہے (LRU/LFU)؛ ایک غلط policy خاموشی سے آپ کا hot set گرا دیتی ہے۔

Cache-aside بمقابلہ read-through

TTL + invalidation

Stampede protection اور hot keys

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات