प्रति मिनेट लाखौं request मा DB load घटाउन कसरी cache गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

DB अगाडि एउटा **cache-aside** layer (Redis/Memcached) राख्नुहोस् ताकि read memory हानोस्, entry लाई **TTL** दिनुहोस् र **write मा invalidate** गर्नुहोस्, **stampede protection** थप्नुहोस् ताकि cold key ले DB मा thundering herd नछोडोस्, र **hot key** लाई replica मा फैलाउनुहोस् ताकि एउटा लोकप्रिय 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×** घटाओस्। प्रति मिनेट लाखौं request मा DB ले हरेक read serve गर्न सक्दैन — cache ले नै संख्या मिलाउँछ।

## TTL + invalidation

cache ताजा राख्ने दुई तरिका, र तपाईंलाई प्रायः दुवै चाहिन्छ। **TTL** ले staleness सीमित गर्छ — entry N second पछि expire हुन्छ त्यसैले गलत data आफैँ निको हुन्छ। **Explicit invalidation** ले correctness का लागि write मा key delete/update गर्छ जुन TTL पर्खन सक्दैन। classic bug invalidation बिना cache गर्नु र मिनेटौं stale data serve गर्नु हो; सूक्ष्म चाहिँ एउटै write मा invalidate *र* set गर्नु, जुन race हुन्छ।

## Stampede protection र hot key

- **Stampede (thundering herd):** hot key expire हुँदा, हजारौं concurrent miss एकैचोटि DB हान्छन् र यसलाई ढाल्न सक्छन्। **per-key lock/single-flight** (एउटा request मात्र recompute गर्छ, अरू पर्खन्छन्) वा expiry अघि **early/probabilistic refresh** ले सच्याउनुहोस्।
- **Hot key:** एउटा key (celebrity को profile) ले एउटा Redis node को CPU/network saturate गर्न सक्छ। फैलाउनुहोस् — key लाई node हरूमा replicate गर्नुहोस्, वा सबैभन्दा hot item का लागि Redis अगाडि सानो local in-process cache थप्नुहोस्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले "Redis थप" भन्दा अगाडि सोच्नुभएको हेर्न चाहन्छन्। राम्रो: TTL सहित cache-aside। उत्कृष्ट: तपाईं **stampede protection, invalidation strategy, hot-key handling, र cache outage मा के हुन्छ** नाम दिनुहुन्छ। जाल भनेको cache सधैँ up छ भनेर मान्नु हो — Redis मर्‍यो र हरेक miss DB मा झर्‍यो भने, तपाईं DB पनि ढाल्ने **cache-avalanche** पाउनुहुन्छ।

## ट्रेड-अफ र failure mode

- **Staleness बनाम load:** छोटो TTL = ताजा तर बढी miss; लामो TTL = कम miss तर बढी stale। प्रति data tune गर्नुहोस्।
- **Cache avalanche:** धेरै key सँगै expire हुँदा (एउटै TTL) load spike हुन्छ — TTL लाई **jitter** गर्नुहोस्।
- **Consistency:** cache र DB बहकिन सक्छन्; money-critical read का लागि DB पढ्नुहोस् वा write-through प्रयोग गर्नुहोस्।
- **Memory eviction:** दबाबमा Redis ले policy (LRU/LFU) अनुसार evict गर्छ; गलत policy ले चुपचाप तपाईंको hot set drop गर्छ।

Cache-aside बनाम read-through

TTL + invalidation

Stampede protection र hot key

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू