ভারী contention-এ একটি hot key বা hot row কীভাবে সামলাবেন?

Question

IT Interview Practice · Accepted Answer

**সব traffic একটি key-তে চালানো বন্ধ করুন: hot key-কে N sub-key-এ (sharded counter) split করুন, duplicate read coalesce করুন, একটি local cache থেকে পরিবেশন করুন, এবং write batch করুন যাতে প্রতিটি request-এ একটি row update না হয়।** একটি viral post-এ একটি একক "likes" counter সেকেন্ডে ৫০k write নিতে পারে — একটি 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 শীতল row-এ পরিণত করে, lock contention ~N দিয়ে কমায়। Read একটি ছোট fan-in খরচ দেয়।
- **Request coalescing (single-flight).** ১০k request একসাথে একই key চাইলে, **একটি**-কে DB-তে আঘাত করতে দিন এবং বাকিদের সেই in-flight ফলাফলে অপেক্ষা করান। একটি cache-miss stampede-কে row চূর্ণ করা থেকে বিরত রাখে।
- **Local (in-process) cache.** প্রতিটি app node-এ hot মান একটি ছোট TTL-এর জন্য cache করুন (যেমন ১s)। একটি read-hot key-এর জন্য, সেটি সেকেন্ডে হাজার হাজার read-কে একটি refresh-এ সংকুচিত করে — সামান্য staleness মেনে।
- **Write batching.** memory-তে increment buffer করুন এবং সেকেন্ডে একবার `+= 500` flush করুন ৫০০টি একক update-এর বদলে। সেকেন্ডে একটি row update ৫০০-এর বদলে contention পুরোপুরি সরায়।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার দেখতে চান আপনি নির্ণয় করেন **contention কোথায়** এবং read-hot বনাম write-hot-এর সঙ্গে fix মেলান। Read-hot → cache + coalescing; write-hot → sharded counter + batching। ভালো উত্তর কৌশল তালিকা করে; দারুণ উত্তর লক্ষ্য করে যে sharding **read cost-কে write scalability-র জন্য** trade করে, এবং batching/caching **freshness-কে throughput-এর জন্য** trade করে।

**ট্রেড-অফ ও ফাঁদ:** sharded counter exact real-time total-কে কঠিন করে (আপনি shard sum করেন) এবং "শূন্যের নিচে decrement" logic জটিল করে। Local cache node জুড়ে drift করে — একটি like count-এর জন্য ঠিক, একটি bank balance-এর জন্য ভুল। Batching flush-এর আগে একটি node crash করলে buffered write হারানোর ঝুঁকি রাখে, তাই এটি idempotent/আনুমানিক counter-এর জন্য উপযুক্ত, টাকার জন্য নয়। data-এর consistency প্রয়োজন যে mitigation অনুমতি দেয় তা বাছুন।

একটি contended row-এর বদলে fan-out

কৌশল

ইন্টারভিউ দৃষ্টিভঙ্গি

সম্পর্কিত প্রশ্ন