जड contention खाली एक hot key किंवा hot row तुम्ही कशी हाताळाल?

Question

IT Interview Practice · Accepted Answer

**सर्व traffic एका key ला funnel करणे थांबवा: 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 घेऊ शकतो — प्रत्येक transaction त्याच lock साठी झगडत असल्याने एक row एक serialization bottleneck बनते.

## एका 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 cooler 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 साठी cache करा (उदा. 1s). एका read-hot key साठी, ते हजारो reads/sec एका refresh मध्ये कोसळवते — किंचित staleness स्वीकारून.
- **Write batching.** memory मध्ये increments buffer करा आणि 500 single updates ऐवजी दर सेकंदाला एकदा `+= 500` flush करा. 500 ऐवजी दर सेकंदाला एक row update contention पूर्णपणे काढून टाकते.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्ही **contention कुठे आहे** हे diagnose करता आणि fix ला read-hot vs write-hot शी जुळवता का हे पाहू इच्छितो. Read-hot → cache + coalescing; write-hot → sharded counters + batching. चांगले उत्तर तंत्रांची यादी करते; उत्तम उत्तर लक्षात घेते की sharding **read cost ला write scalability साठी** trade करते, आणि batching/caching **freshness ला throughput साठी** trade करतात.

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

एका contended row ऐवजी fan-out

तंत्रे

मुलाखतीचा दृष्टिकोन

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