Ta yaya za ka sarrafa hot key ko hot row a ƙarƙashin heavy contention?

Question

IT Interview Practice · Accepted Answer

**Ka daina tura duk traffic zuwa key ɗaya: raba hot key zuwa sub-keys N (sharded counters), coalesce duplicate reads, bauta daga local cache, kuma ka batch writes domin row ɗaya kada a update shi a kowane request.** Single "likes" counter a viral post na iya ɗaukar writes 50k/daƙiƙa — row ɗaya yana zama serialization bottleneck yayin da kowace transaction ke faɗa da same lock.

## Fan-out maimakon contended row ɗaya

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

## Dabaru

- **Sharded counter / key splitting.** Rubuta zuwa `likes:123:{0..N}` da aka zaɓa a random; ainihin count shi ne `SUM`. Wannan yana mai da hot row ɗaya zuwa cooler rows N, yana rage lock contention da kusan N. Reads suna biyan ƙaramin fan-in cost.
- **Request coalescing (single-flight).** Idan requests 10k suna son same key a lokaci guda, bar **ɗaya** ya bugi DB kuma ka sa sauran su jira wannan in-flight result. Yana hana cache-miss stampede murkushe row.
- **Local (in-process) cache.** Cache hot value a kowane app node na short TTL (misali 1s). Ga read-hot key, wannan yana rushe dubban reads/daƙiƙa zuwa refresh ɗaya — yana karɓar ɗan staleness.
- **Write batching.** Buffer increments a memory kuma ka flush `+= 500` sau ɗaya a daƙiƙa maimakon 500 single updates. Row update ɗaya a daƙiƙa maimakon 500 yana cire contention gaba ɗaya.

## Ra'ayin hira

Mai yin hirar yana son ganin ka diagnose **inda contention ke** kuma ka daidaita fix zuwa read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Amsa mai kyau tana lissafa dabaru; amsa mai kyau sosai tana lura cewa sharding yana sulhu **read cost don write scalability**, kuma batching/caching suna sulhu **freshness don throughput**.

**Sulhu & tarkuna:** sharded counters suna sa exact real-time totals mai wuya (kana sum shards) kuma suna dagula "decrement below zero" logic. Local caches suna kauda a kan nodes — yayi kyau ga like count, kuskure ga bank balance. Batching yana haɗarin rasa buffered writes idan node ya crash kafin flush, don haka yayi kyau ga idempotent/approximate counters, ba kuɗi ba. Zaɓi mitigation da consistency needs na data ke bayarwa.

Fan-out maimakon contended row ɗaya

Dabaru

Ra'ayin hira

Tambayoyi masu alaƙa