heavy 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 ஆகாது.** ஒரு வைரல் 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-க்கு (எ.கா. 1s) cache செய்யுங்கள். ஒரு read-hot key-க்கு, அது ஆயிரக்கணக்கான reads/sec-ஐ ஒரு refresh ஆக collapse செய்கிறது — சிறிது staleness-ஐ ஏற்று.
- **Write batching.** memory-இல் increments-ஐ buffer செய்து, 500 single updates-க்குப் பதிலாக ஒரு வினாடிக்கு ஒருமுறை `+= 500` flush செய்யுங்கள். ஒரு வினாடிக்கு ஒரு row update, 500 அல்ல, contention-ஐ முழுவதுமாக அகற்றுகிறது.

## நேர்காணல் கண்ணோட்டம்

**contention எங்கே** என்பதைக் கண்டறிந்து read-hot vs write-hot-க்கு fix-ஐப் பொருத்துவதை நேர்காணல் செய்பவர் பார்க்க விரும்புகிறார். 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 செய்கிறீர்கள்) மற்றும் "zero-க்குக் கீழே decrement" logic-ஐ சிக்கலாக்குகின்றன. Local caches nodes முழுவதும் drift ஆகின்றன — ஒரு like count-க்கு பரவாயில்லை, ஒரு bank balance-க்கு தவறு. Batching ஒரு node flush-க்கு முன் crash ஆனால் buffered writes-ஐ இழக்கும் அபாயம், எனவே இது idempotent/approximate counters-க்கு பொருந்துகிறது, பணத்திற்கு அல்ல. data-இன் consistency தேவைகள் அனுமதிக்கும் mitigation-ஐத் தேர்ந்தெடுங்கள்.

ஒரு contended row-க்குப் பதிலாக fan-out

நுட்பங்கள்

நேர்காணல் கண்ணோட்டம்

தொடர்புடைய கேள்விகள்