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

Question

IT Interview Practice · Accepted Answer

**Slutt å trakte all trafikk til én key: del den hot key-en i N sub-keys (sharded counters), koalescer duplikate lesninger, server fra en lokal cache, og batch writes slik at én rad ikke oppdateres ved hver request.** En enkelt "likes"-teller på et viralt innlegg kan ta 50k writes/sek — én rad blir en serialiserings-flaskehals ettersom hver transaksjon slåss om samme lock.

## Fan-out i stedet for én contended rad

```text
                 50k inc/sek på post:123
                          │
             hash(request) % N   (del key-en)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM ved lesning = total     (lesning fan-in)
```

## Teknikker

- **Sharded counter / key-splitting.** Skriv til `likes:123:{0..N}` valgt tilfeldig; den sanne tellingen er `SUM`. Dette gjør én hot row til N kjøligere rader, og kutter lock-contention med ~N. Lesninger betaler en liten fan-in-kostnad.
- **Request coalescing (single-flight).** Hvis 10k requester vil ha samme key samtidig, la **én** treffe DB-en og la resten vente på det in-flight-resultatet. Forhindrer at en cache-miss-stampede knuser raden.
- **Lokal (in-process) cache.** Cache den hot verdien i hver app-node for en kort TTL (f.eks. 1s). For en lese-hot key kollapser det tusenvis av lesninger/sek til én refresh — mot litt staleness.
- **Write-batching.** Buffre inkrementer i minne og flush `+= 500` én gang per sekund i stedet for 500 enkelt-oppdateringer. Én rad-oppdatering per sekund i stedet for 500 fjerner contention helt.

## Intervjuperspektiv

Intervjueren vil se at du diagnostiserer **hvor contention er** og matcher fiksen til lese-hot vs write-hot. Lese-hot → cache + coalescing; write-hot → sharded counters + batching. Godt svar lister teknikker; utmerket svar bemerker at sharding veksler **lese-kostnad mot write-skalerbarhet**, og at batching/caching veksler **friskhet mot throughput**.

**Avveininger og feller:** sharded counters gjør eksakte sanntidstotaler vanskeligere (du summerer shards) og kompliserer "dekrement under null"-logikk. Lokale cacher drifter over noder — greit for en like-teller, feil for en banksaldo. Batching risikerer å miste buffrede writes hvis en node krasjer før flush, så det passer idempotente/tilnærmede tellere, ikke penger. Velg dempingen dataens konsistensbehov tillater.

Fan-out i stedet for én contended rad

Teknikker

Intervjuperspektiv

Relaterte spørsmål