ભારે contention હેઠળ hot key કે hot row ને તમે કેવી રીતે સંભાળશો?

Question

IT Interview Practice · Accepted Answer

**બધો traffic એક key પર funnel કરવાનું બંધ કરો: hot key ને N sub-keys (sharded counters) માં split કરો, 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)
```

## Techniques

- **Sharded counter / key splitting.** `likes:123:{0..N}` પર random પસંદ કરીને લખો; સાચી count એ `SUM` છે. આ એક hot row ને N cooler rows માં ફેરવે છે, lock contention ~N વડે ઘટાડે છે. Reads નાનું fan-in cost ચૂકવે છે.
- **Request coalescing (single-flight).** જો 10k requests એકસાથે એ જ key ઇચ્છે, તો **એક** ને DB પર hit કરવા દો અને બાકીની ને તે in-flight result પર રાહ જોવા દો. cache-miss stampede ને row crush કરવાથી અટકાવે છે.
- **Local (in-process) cache.** hot value ને દરેક app node માં ટૂંકા 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. Good answer techniques list કરે છે; great answer નોંધે છે કે sharding **write scalability માટે read cost** trade કરે છે, અને batching/caching **throughput માટે freshness** trade કરે છે.

**Trade-offs & traps:** sharded counters exact real-time totals ને મુશ્કેલ બનાવે છે (તમે shards sum કરો) અને "decrement below zero" logic ને જટિલ કરે છે. Local caches nodes પર drift કરે છે — like count માટે ઠીક, bank balance માટે ખોટું. Batching node flush પહેલાં crash થાય તો buffered writes ગુમાવવાનું જોખમ છે, તેથી તે idempotent/approximate counters ને અનુકૂળ છે, money ને નહીં. data ની consistency needs મંજૂરી આપે તે mitigation પસંદ કરો.

એક contended row ને બદલે fan-out

Techniques

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

સંબંધિત પ્રશ્નો