Si e menaxhoni një hot key ose hot row nën contention të rëndë?

Question

IT Interview Practice · Accepted Answer

**Ndaloni kanalizimin e gjithë trafikut te një key: ndani hot key-in në N sub-keys (sharded counters), bashkoni leximet dublikate, shërbeni nga një local cache, dhe batch-oni shkrimet që një row të mos përditësohet në çdo request.** Një counter "likes" i vetëm në një post viral mund të marrë 50k shkrime/sek — një row bëhet një bottleneck serializimi ndërsa çdo transaksion lufton për të njëjtin lock.

## Fan-out në vend të një row të contended

```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)
```

## Teknika

- **Sharded counter / key splitting.** Shkruani te `likes:123:{0..N}` të zgjedhur në mënyrë të rastësishme; numri i vërtetë është `SUM`. Kjo e kthen një row të nxehtë në N rreshta më të ftohtë, duke prerë lock contention me ~N. Leximet paguajnë një kosto të vogël fan-in.
- **Request coalescing (single-flight).** Nëse 10k request duan të njëjtin key njëherësh, lëreni **një** të godasë DB-në dhe të tjerët të presin atë rezultat in-flight. Parandalon që një cache-miss stampede të shtypë row-in.
- **Local (in-process) cache.** Cache vlerën e nxehtë në çdo node aplikacioni për një TTL të shkurtër (p.sh. 1s). Për një key read-hot, kjo bashkon mijëra lexime/sek në një refresh — duke pranuar staleness të lehtë.
- **Write batching.** Buffer-oni increments në memorie dhe bëni flush `+= 500` një herë në sekondë në vend të 500 update-e të veçantë. Një update row në sekondë në vend të 500 heq plotësisht contention-in.

## Këndvështrimi i intervistës

Intervistuesi dëshiron t'ju shohë të diagnostikoni **ku është contention-i** dhe të përputhni rregullimin me read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Përgjigja e mirë liston teknika; përgjigja e shkëlqyer vëren se sharding bën kompromis **kosto leximi për shkallëzueshmëri shkrimi**, dhe se batching/caching bëjnë kompromis **freskinë për throughput**.

**Kompromiset & kurthet:** sharded counters e bëjnë totalin e saktë real-time më të vështirë (ju mblidhni shards) dhe komplikojnë logjikën "decrement nën zero". Local caches divergojnë nëpër node — në rregull për një like count, gabim për një bank balance. Batching rrezikon humbjen e shkrimeve të buffer-uara nëse një node rrëzohet para flush, kështu që i përshtatet counter-ave idempotentë/të përafërt, jo parave. Zgjidhni zbutjen që lejojnë nevojat e konsistencës së të dhënave.

Fan-out në vend të një row të contended

Teknika

Këndvështrimi i intervistës

Pyetje të ngjashme