भारी contention मा hot key वा hot row कसरी सम्हाल्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

**सबै traffic एउटा key मा खन्याउन बन्द गर्नुहोस्: hot key लाई N sub-key (sharded counter) मा विभाजन गर्नुहोस्, duplicate read coalesce गर्नुहोस्, local cache बाट serve गर्नुहोस्, र write batch गर्नुहोस् ताकि एउटा row हरेक request मा update नहोस्।** viral post मा एउटै "likes" counter ले 50k write/sec लिन सक्छ — एउटा row serialization bottleneck बन्छ किनकि हरेक transaction एउटै lock का लागि लड्छ।

## एउटा contended row को सट्टा fan-out

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## तरिका हरू

- **Sharded counter / key splitting.** random मा छानिएको `likes:123:{0..N}` मा लेख्नुहोस्; साँचो count `SUM` हो। यसले एउटा hot row लाई N वटा चिसो row मा परिणत गर्छ, lock contention लाई ~N ले घटाउँछ। Read ले सानो fan-in लागत तिर्छ।
- **Request coalescing (single-flight).** 10k request एउटै key एकैचोटि चाहन्छन् भने, **एउटा** लाई DB हान्न दिनुहोस् र बाँकीलाई त्यो in-flight नतिजा पर्खन दिनुहोस्। cache-miss stampede ले row कुल्चनबाट रोक्छ।
- **Local (in-process) cache.** hot value लाई प्रत्येक app node मा छोटो TTL (जस्तै 1s) का लागि cache गर्नुहोस्। read-hot key का लागि, त्यसले हजारौं read/sec लाई एउटा refresh मा घटाउँछ — अलि staleness स्वीकारेर।
- **Write batching.** memory मा increment buffer गर्नुहोस् र 500 single update को सट्टा प्रति second एक पटक `+= 500` flush गर्नुहोस्। 500 को सट्टा प्रति second एउटा row update ले contention पूरै हटाउँछ।

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

अन्तर्वार्ताकारले तपाईंले **contention कहाँ छ** निदान गर्नुहुन्छ र fix लाई read-hot बनाम write-hot सँग मिलाउनुहुन्छ कि हेर्न चाहन्छन्। Read-hot → cache + coalescing; write-hot → sharded counter + batching। राम्रो उत्तरले तरिका सूचीबद्ध गर्छ; उत्कृष्टले sharding ले **read cost लाई write scalability सँग trade** गर्छ, र batching/caching ले **freshness लाई throughput सँग trade** गर्छ भनेर बताउँछ।

**ट्रेड-अफ र जाल:** sharded counter ले exact real-time total गाह्रो बनाउँछ (तपाईं shard sum गर्नुहुन्छ) र "शून्य भन्दा तल decrement" logic जटिल बनाउँछ। Local cache node बीच बहकिन्छ — like count का लागि ठीक, bank balance का लागि गलत। Batching ले flush अघि node crash भए buffered write गुमाउने जोखिम राख्छ, त्यसैले यो idempotent/approximate counter का लागि उपयुक्त, पैसा का लागि होइन। data को consistency आवश्यकताले दिने न्यूनीकरण छान्नुहोस्।

एउटा contended row को सट्टा fan-out

तरिका हरू

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

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