Hvordan håndterer du en hot key eller hot row under tung kontention?

Question

IT Interview Practice · Accepted Answer

**Stop med at kanalisere al trafik til én nøgle: split hot key'en i N sub-keys (sharded counters), koales duplikerede reads, servér fra en lokal cache, og batch writes så én row ikke opdateres ved hver request.** En enkelt "likes"-tæller på et viralt opslag kan tage 50k writes/sek — én row bliver en serialiserings-flaskehals, når hver transaction kæmper om den samme lock.

## Fan-out i stedet for én kontenderet row

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

## Teknikker

- **Sharded counter / key splitting.** Skriv til `likes:123:{0..N}` valgt tilfældigt; den sande tæller er `SUM`. Dette gør én hot row til N køligere rows, hvilket skærer lock-kontention med ~N. Reads betaler en lille fan-in-omkostning.
- **Request coalescing (single-flight).** Hvis 10k requests vil have samme nøgle på én gang, lad **én** ramme DB'en og lad resten vente på det in-flight-resultat. Forhindrer en cache-miss-stampede i at knuse rowen.
- **Lokal (in-process) cache.** Cache den hotte værdi i hver app-node i en kort TTL (fx 1s). For en read-hot nøgle kollapser det tusindvis af reads/sek til én refresh — ved at acceptere let forældelse.
- **Write batching.** Buffer increments i hukommelsen og flush `+= 500` én gang pr. sekund i stedet for 500 enkelte updates. Én row-update pr. sekund i stedet for 500 fjerner kontentionen helt.

## Interview-perspektiv

Intervieweren vil se dig diagnosticere **hvor kontentionen er** og matche fixet til read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Godt svar lister teknikker; fremragende svar bemærker, at sharding afvejer **read-omkostning for write-skalerbarhed**, og at batching/caching afvejer **friskhed for throughput**.

**Trade-offs & fælder:** sharded counters gør eksakte real-time-totaler sværere (du summerer shards) og komplicerer "dekrementér under nul"-logik. Lokale caches drifter over noder — fint for en like-tæller, forkert for en banksaldo. Batching risikerer at miste bufferede writes hvis en node crasher før flush, så det passer til idempotente/omtrentlige tællere, ikke penge. Vælg den afbødning, dataens konsistensbehov tillader.

Fan-out i stedet for én kontenderet row

Teknikker

Interview-perspektiv

Relaterede spørgsmål