Hur hanterar du en het nyckel eller het rad under tung contention?

Question

IT Interview Practice · Accepted Answer

**Sluta tratta all trafik till en nyckel: dela den heta nyckeln i N sub-nycklar (shardade räknare), slå ihop dubbletta läsningar, servera från en lokal cache, och batcha skrivningar så att en rad inte uppdateras vid varje request.** En enda "likes"-räknare på ett viralt inlägg kan ta 50k skrivningar/sek — en rad blir en serialiseringsflaskhals när varje transaktion slåss om samma lås.

## Fan-out istället för en contended rad

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

## Tekniker

- **Shardad räknare / nyckeldelning.** Skriv till `likes:123:{0..N}` vald slumpmässigt; det sanna antalet är `SUM`. Detta förvandlar en het rad till N svalare rader, vilket minskar låscontention med ~N. Läsningar betalar en liten fan-in-kostnad.
- **Request coalescing (single-flight).** Om 10k requester vill ha samma nyckel samtidigt, låt **en** träffa DB:n och låt resten vänta på det pågående resultatet. Förhindrar att en cache-miss-stampede krossar raden.
- **Lokal (in-process) cache.** Cacha det heta värdet i varje app-nod för en kort TTL (t.ex. 1s). För en läs-het nyckel kollapsar det tusentals läsningar/sek till en refresh — accepterar lätt inaktualitet.
- **Skrivbatchning.** Buffra inkrement i minnet och flusha `+= 500` en gång per sekund istället för 500 enskilda uppdateringar. En raduppdatering per sekund istället för 500 tar bort contention helt.

## Intervjuperspektiv

Intervjuaren vill se dig diagnostisera **var contention finns** och matcha fixen till läs-het vs skriv-het. Läs-het → cache + coalescing; skriv-het → shardade räknare + batchning. Bra svar listar tekniker; utmärkt svar noterar att sharding avväger **läskostnad mot skrivbarhet**, och att batchning/caching avväger **färskhet mot throughput**.

**Avvägningar & fällor:** shardade räknare gör exakta realtidstotaler svårare (du summerar shards) och komplicerar "dekrementera under noll"-logik. Lokala cacher driver isär över noder — okej för ett like-antal, fel för ett banksaldo. Batchning riskerar att förlora buffrade skrivningar om en nod kraschar före flush, så det passar idempotenta/approximativa räknare, inte pengar. Välj den mildring som datans konsistensbehov tillåter.

Fan-out istället för en contended rad

Tekniker

Intervjuperspektiv

Relaterade frågor