Unashughulikiaje hot key au hot row chini ya contention kubwa?

Question

IT Interview Practice · Accepted Answer

**Acha kupeleka traffic yote kwenye key moja: gawanya hot key kuwa N sub-keys (sharded counters), coalesce duplicate reads, tumikia kutoka local cache, na batch writes ili row moja isiupdate kwa kila request.** "Likes" counter moja kwenye post ya viral inaweza kuchukua writes 50k/sekunde — row moja huwa serialization bottleneck kila transaction ikigombania lock ile ile.

## Fan-out badala ya row moja iliyogombaniwa

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

## Mbinu

- **Sharded counter / key splitting.** Andika kwa `likes:123:{0..N}` iliyochaguliwa kwa nasibu; hesabu halisi ni `SUM`. Hii hubadilisha hot row moja kuwa N rows za baridi zaidi, ikipunguza lock contention kwa ~N. Reads hulipa fan-in cost ndogo.
- **Request coalescing (single-flight).** Ikiwa requests 10k zinataka key ile ile kwa mara moja, ruhusu **moja** kupiga DB na uwe na zingine zisubiri matokeo hayo yaliyo in-flight. Huzuia cache-miss stampede kupondaponda row.
- **Local (in-process) cache.** Cache hot value katika kila app node kwa TTL fupi (mfano 1s). Kwa read-hot key, hilo huporomosha maelfu ya reads/sekunde kuwa refresh moja — ikikubali staleness kidogo.
- **Write batching.** Buffer maongezeko katika memory na flush `+= 500` mara moja kwa sekunde badala ya updates 500 za pekee. Update moja ya row kwa sekunde badala ya 500 huondoa contention kabisa.

## Mtazamo wa mahojiano

Mhojiwa anataka kukuona ukigundua **contention iko wapi** na kulinganisha suluhisho na read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Jibu zuri huorodhesha mbinu; jibu bora sana hutaja kuwa sharding hufanya maelewano ya **read cost kwa write scalability**, na kwamba batching/caching hufanya maelewano ya **freshness kwa throughput**.

**Maelewano na mitego:** sharded counters hufanya exact real-time totals kuwa ngumu zaidi (unajumlisha shards) na huchanganya "decrement below zero" logic. Local caches hupotoka kuvuka nodes — sawa kwa like count, mbaya kwa bank balance. Batching huhatarisha kupoteza buffered writes ikiwa node itaanguka kabla ya flush, hivyo hufaa idempotent/approximate counters, si pesa. Chagua mitigation ambayo consistency needs za data huruhusu.

Fan-out badala ya row moja iliyogombaniwa

Mbinu

Mtazamo wa mahojiano

Maswali yanayohusiana