Come gestisci una hot key o hot row sotto forte contesa?

Question

IT Interview Practice · Accepted Answer

**Smetti di convogliare tutto il traffico su una sola chiave: suddividi la hot key in N sotto-chiavi (contatori sharded), coalesci le letture duplicate, servi da una cache locale, e fai batch delle scritture così che una riga non venga aggiornata a ogni richiesta.** Un singolo contatore "like" su un post virale può prendere 50k scritture/sec — una riga diventa un collo di bottiglia da serializzazione mentre ogni transazione si contende lo stesso lock.

## Fan-out invece di una riga contesa

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

## Tecniche

- **Contatore sharded / key splitting.** Scrivi su `likes:123:{0..N}` scelto casualmente; il conteggio vero è la `SUM`. Questo trasforma una riga calda in N righe più fredde, riducendo la contesa sui lock di ~N. Le letture pagano un piccolo costo di fan-in.
- **Request coalescing (single-flight).** Se 10k richieste vogliono la stessa chiave contemporaneamente, lascia che **una** colpisca il DB e fai attendere le altre su quel risultato in-flight. Impedisce che uno stampede da cache-miss schiacci la riga.
- **Cache locale (in-process).** Metti in cache il valore caldo in ogni nodo app per un TTL breve (es. 1s). Per una chiave read-hot, questo collassa migliaia di letture/sec in un refresh — accettando lieve staleness.
- **Write batching.** Bufferizza gli incrementi in memoria e fai flush di `+= 500` una volta al secondo invece di 500 aggiornamenti singoli. Un aggiornamento di riga al secondo invece di 500 elimina del tutto la contesa.

## Prospettiva del colloquio

L'intervistatore vuole vederti diagnosticare **dove sta la contesa** e adattare la soluzione a read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → contatori sharded + batching. La buona risposta elenca le tecniche; l'eccellente nota che lo sharding baratta **costo di lettura per scalabilità in scrittura**, e che batching/caching barattano **freschezza per throughput**.

**Compromessi e trappole:** i contatori sharded rendono più difficili i totali esatti in tempo reale (sommi gli shard) e complicano la logica del "decremento sotto zero". Le cache locali divergono tra i nodi — va bene per un conteggio di like, sbagliato per un saldo bancario. Il batching rischia di perdere le scritture bufferizzate se un nodo va in crash prima del flush, quindi si addice a contatori idempotenti/approssimati, non al denaro. Scegli la mitigazione che le esigenze di consistenza del dato permettono.

Fan-out invece di una riga contesa

Tecniche

Prospettiva del colloquio

Domande correlate