भारी contention के तहत आप एक hot key या hot row कैसे संभालते हैं?

Question

IT Interview Practice · Accepted Answer

**सारा traffic एक key पर भेजना बंद करें: hot key को N sub-keys (sharded counters) में बांटें, duplicate reads को coalesce करें, एक local cache से serve करें, और writes को batch करें ताकि एक row हर request पर update न हो।** एक viral post पर एक अकेला "likes" counter 50k writes/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 ठंडी rows में बदल देता है, lock contention को ~N गुना काटते हुए। Reads एक छोटी fan-in cost चुकाते हैं।
- **Request coalescing (single-flight).** अगर 10k requests एक साथ एक ही key चाहती हैं, **एक** को DB पर लगने दें और बाकी को उस in-flight result पर इंतज़ार कराएं। एक cache-miss stampede को row को कुचलने से रोकता है।
- **Local (in-process) cache.** hot value को हर app node में एक छोटे TTL (जैसे 1s) के लिए cache करें। एक read-hot key के लिए, यह हज़ारों reads/sec को एक refresh में समेट देता है — थोड़ी staleness स्वीकार करते हुए।
- **Write batching.** increments को memory में buffer करें और 500 single updates के बजाय प्रति सेकंड एक बार `+= 500` flush करें। 500 के बजाय प्रति सेकंड एक row update contention को पूरी तरह हटा देता है।

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

Interviewer आपको **contention कहां है** diagnose करते और fix को read-hot बनाम write-hot से match करते देखना चाहता है। Read-hot → cache + coalescing; write-hot → sharded counters + batching। अच्छा जवाब तकनीकें सूचीबद्ध करता है; बढ़िया जवाब नोट करता है कि sharding **write scalability के लिए read cost** trade करता है, और batching/caching **throughput के लिए freshness** trade करते हैं।

**ट्रेड-ऑफ़ और जाल:** sharded counters exact real-time totals को कठिन बनाते हैं (आप shards sum करते हैं) और "शून्य से नीचे decrement" logic को जटिल करते हैं। Local caches nodes में drift करते हैं — एक like count के लिए ठीक, एक bank balance के लिए गलत। Batching एक node के flush से पहले crash होने पर buffered writes खोने का जोखिम है, इसलिए यह idempotent/approximate counters के लिए उपयुक्त है, पैसे के लिए नहीं। वह mitigation चुनें जो data की consistency ज़रूरतें अनुमति दें।

एक contended row के बजाय fan-out

तकनीकें

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

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