ਤੁਸੀਂ ਭਾਰੀ 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 ਉੱਤੇ ਇੱਕ single "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 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 ਨੂੰ ਢਾਹੁਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
- **Local (in-process) cache.** hot value ਨੂੰ ਹਰ app node ਵਿੱਚ ਇੱਕ ਛੋਟੇ TTL (ਜਿਵੇਂ 1s) ਲਈ cache ਕਰੋ। ਇੱਕ read-hot key ਲਈ, ਇਹ ਹਜ਼ਾਰਾਂ reads/sec ਨੂੰ ਇੱਕ refresh ਵਿੱਚ ਢਾਹ ਦਿੰਦਾ ਹੈ — ਥੋੜ੍ਹੀ staleness ਸਵੀਕਾਰ ਕਰਦੇ ਹੋਏ।
- **Write batching.** increments ਨੂੰ memory ਵਿੱਚ buffer ਕਰੋ ਅਤੇ 500 single updates ਦੀ ਬਜਾਏ ਹਰ ਸਕਿੰਟ ਇੱਕ ਵਾਰ `+= 500` flush ਕਰੋ। 500 ਦੀ ਬਜਾਏ ਹਰ ਸਕਿੰਟ ਇੱਕ row update contention ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ diagnose ਕਰੋ ਕਿ **contention ਕਿੱਥੇ ਹੈ** ਅਤੇ 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 ਨੂੰ ਗੁੰਝਲਦਾਰ ਕਰਦੇ ਹਨ। Local caches nodes ਦੇ ਪਾਰ ਭਟਕਦੇ ਹਨ — ਇੱਕ like count ਲਈ ਠੀਕ, ਇੱਕ bank balance ਲਈ ਗਲਤ। Batching flush ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ node crash ਹੋ ਜਾਣ ਉੱਤੇ buffered writes ਗੁਆਉਣ ਦਾ ਖਤਰਾ ਹੈ, ਇਸ ਲਈ ਇਹ idempotent/approximate counters ਲਈ ਢੁਕਵਾਂ ਹੈ, ਪੈਸੇ ਲਈ ਨਹੀਂ। ਓਹ mitigation ਚੁਣੋ ਜਿਸਦੀ data ਦੀਆਂ consistency ਲੋੜਾਂ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ।

ਇੱਕ contended row ਦੀ ਬਜਾਏ fan-out

ਤਕਨੀਕਾਂ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਸੰਬੰਧਿਤ ਸਵਾਲ