بھاری 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 لاگت ادا کرتے ہیں۔
- **Request coalescing (single-flight)۔** اگر 10k requests بیک وقت ایک ہی key چاہتی ہیں، تو **ایک** کو DB hit کرنے دیں اور باقی کو اُس in-flight نتیجے پر انتظار کرائیں۔ یہ ایک cache-miss stampede کو row کچلنے سے روکتا ہے۔
- **Local (in-process) cache۔** hot value کو ہر app node میں ایک مختصر TTL کے لیے cache کریں (مثلاً 1s)۔ ایک read-hot key کے لیے، یہ ہزاروں reads/sec کو ایک refresh میں سمیٹ دیتا ہے — قدرے staleness قبول کرتے ہوئے۔
- **Write batching۔** increments کو memory میں buffer کریں اور 500 single updates کے بجائے فی سیکنڈ ایک بار `+= 500` flush کریں۔ 500 کے بجائے فی سیکنڈ ایک row update contention کو مکمل طور پر ختم کر دیتا ہے۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا دیکھنا چاہتا ہے کہ آپ **contention کہاں ہے** اس کی تشخیص کریں اور fix کو read-hot بمقابلہ 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 کے لیے غلط۔ Batching flush سے پہلے node crash ہو تو buffered writes کھونے کا خطرہ رکھتا ہے، لہٰذا یہ idempotent/approximate counters کے لیے موزوں ہے، پیسے کے لیے نہیں۔ وہ تخفیف چنیں جو data کی consistency ضروریات اجازت دیں۔

ایک contended row کے بجائے fan-out

تکنیکیں

انٹرویو کا نقطۂ نظر

متعلقہ سوالات