Hoe ga je om met een hot key of hot row onder zware contentie?

Question

IT Interview Practice · Accepted Answer

**Stop met al het verkeer naar één key trechteren: splits de hot key in N sub-keys (gesharde tellers), coalesce dubbele reads, serveer uit een lokale cache, en batch writes zodat één row niet bij elke request wordt ge-updatet.** Een enkele "likes"-teller op een virale post kan 50k writes/sec aannemen — één row wordt een serialisatie-bottleneck terwijl elke transactie om dezelfde lock vecht.

## Fan-out in plaats van één ge-contende row

```text
                 50k inc/sec op post:123
                          │
             hash(request) % N   (splits de key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← gesharde tellers
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM bij read = totaal     (read waaiert in)
```

## Technieken

- **Gesharde teller / key-splitsing.** Schrijf naar `likes:123:{0..N}` willekeurig gekozen; de echte teller is de `SUM`. Dit zet één hot row om in N koelere rows, wat lock-contentie met ~N verlaagt. Reads betalen een kleine fan-in-kost.
- **Request coalescing (single-flight).** Als 10k requests tegelijk dezelfde key willen, laat **één** de DB raken en de rest wachten op dat in-flight resultaat. Voorkomt dat een cache-miss-stampede de row verplettert.
- **Lokale (in-process) cache.** Cache de hot waarde in elke app-node voor een korte TTL (bijv. 1s). Voor een read-hot key laat dat duizenden reads/sec instorten tot één refresh — met acceptatie van lichte staleness.
- **Write-batching.** Buffer verhogingen in geheugen en flush `+= 500` één keer per seconde in plaats van 500 losse updates. Eén row-update per seconde in plaats van 500 verwijdert de contentie volledig.

## Interviewperspectief

De interviewer wil je **waar de contentie zit** zien diagnosticeren en de fix zien matchen aan read-hot versus write-hot. Read-hot → cache + coalescing; write-hot → gesharde tellers + batching. Een goed antwoord somt technieken op; een uitstekend antwoord merkt op dat sharding **read-kost inruilt voor write-schaalbaarheid**, en dat batching/caching **versheid inruilt voor throughput**.

**Afwegingen & valkuilen:** gesharde tellers maken exacte real-time totalen moeilijker (je sommeert shards) en compliceren "decrement onder nul"-logica. Lokale caches driften over nodes — prima voor een like-teller, fout voor een banksaldo. Batching riskeert het verlies van gebufferde writes als een node crasht vóór de flush, dus het past bij idempotente/benaderende tellers, niet bij geld. Kies de mitigatie die de consistentiebehoeften van de data toelaten.

Fan-out in plaats van één ge-contende row

Technieken

Interviewperspectief

Gerelateerde vragen