heavy contention కింద ఒక hot key లేదా hot row ను మీరు ఎలా handle చేస్తారు?

Question

IT Interview Practice · Accepted Answer

**అన్ని traffic ను ఒక key కి funnel చేయడం ఆపండి: hot key ను N sub-keys గా split చేయండి (sharded counters), duplicate reads ను coalesce చేయండి, ఒక local cache నుండి serve చేయండి, మరియు writes ను batch చేయండి తద్వారా ప్రతి request పై ఒక row 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)
```

## Techniques

- **Sharded counter / key splitting.** random గా ఎంచుకున్న `likes:123:{0..N}` కి write చేయండి; నిజమైన count `SUM`. ఇది ఒక hot row ను N cooler rows గా మార్చి lock contention ను ~N తగ్గిస్తుంది. Reads ఒక చిన్న fan-in cost ను pay చేస్తాయి.
- **Request coalescing (single-flight).** 10k requests ఒకేసారి అదే key ను కోరితే, **ఒకటి** DB ను తాకనివ్వండి మరియు మిగిలినవి ఆ in-flight result కోసం వేచి ఉండనివ్వండి. ఒక cache-miss stampede row ను చితకకొట్టకుండా నివారిస్తుంది.
- **Local (in-process) cache.** ప్రతి app node లో hot value ను ఒక short TTL కి (ఉదా. 1s) cache చేయండి. ఒక read-hot key కి, అది వేల reads/sec ను ఒక refresh గా collapse చేస్తుంది — కొంచెం staleness ను అంగీకరిస్తూ.
- **Write batching.** memory లో increments ను buffer చేసి 500 single updates కి బదులు సెకనుకు ఒకసారి `+= 500` flush చేయండి. 500 కి బదులు సెకనుకు ఒక row update contention ను పూర్తిగా తొలగిస్తుంది.

## ఇంటర్వ్యూ దృక్కోణం

**contention ఎక్కడ ఉందో** diagnose చేసి fix ను read-hot vs write-hot కి match చేయడం ఇంటర్వ్యూయర్ చూడాలనుకుంటారు. Read-hot → cache + coalescing; write-hot → sharded counters + batching. మంచి సమాధానం techniques ను జాబితా చేస్తుంది; గొప్ప సమాధానం sharding **read cost ను write scalability కోసం trade** చేస్తుందని, మరియు batching/caching **freshness ను throughput కోసం trade** చేస్తాయని గమనిస్తుంది.

**Trade-offs & traps:** sharded counters exact real-time totals ను కష్టతరం చేస్తాయి (మీరు shards ను sum చేస్తారు) మరియు "decrement below zero" logic ను complicate చేస్తాయి. Local caches nodes అంతటా drift అవుతాయి — ఒక like count కి పర్వాలేదు, ఒక bank balance కి తప్పు. Batching flush కు ముందు ఒక node crash అయితే buffered writes ను కోల్పోయే risk — కాబట్టి ఇది money కి కాదు, idempotent/approximate counters కి సరిపోతుంది. data యొక్క consistency needs అనుమతించే mitigation ను ఎంచుకోండి.

ఒక contended row కి బదులు fan-out

Techniques

ఇంటర్వ్యూ దృక్కోణం

సంబంధిత ప్రశ్నలు