Come fai caching per ridurre il carico del DB a milioni di req/min?

Question

IT Interview Practice · Accepted Answer

Metti un layer **cache-aside** (Redis/Memcached) davanti al DB così che le letture colpiscano la memoria, dai alle voci un **TTL** e **invalida in scrittura**, aggiungi **protezione dallo stampede** così che una chiave fredda non scateni un thundering herd sul DB, e distribuisci le **hot key** tra le replica così che una chiave popolare non fonda un singolo nodo.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

Nel **cache-aside** l'app controlla la cache; in caso di miss legge dal DB e popola la cache essa stessa. Nel **read-through** è la libreria di cache a farlo per te. In entrambi i casi l'obiettivo è lo stesso: trasformare una query DB da 5ms in un lookup in memoria da 0,2ms, così una cache con un hit rate del 95% riduce il traffico di lettura sul DB di **20×**. A milioni di req/min il DB semplicemente non può servire ogni lettura — è la cache a far tornare i numeri.

## TTL + invalidazione

Due modi per mantenere fresca la cache, e di solito ti servono entrambi. Il **TTL** limita la staleness — una voce scade dopo N secondi così che i dati errati si auto-riparino. L'**invalidazione esplicita** cancella/aggiorna la chiave in scrittura per una correttezza che non può attendere il TTL. Il bug classico è fare caching senza invalidazione e servire dati stale per minuti; quello più sottile è invalidare *e* fare set nella stessa scrittura, che va in race.

## Protezione dallo stampede e hot key

- **Stampede (thundering herd):** quando una hot key scade, migliaia di miss concorrenti colpiscono tutti il DB insieme e possono metterlo al tappeto. Risolvi con un **lock/single-flight per chiave** (solo una richiesta ricalcola, le altre attendono) o un **refresh anticipato/probabilistico** prima della scadenza.
- **Hot key:** una chiave (il profilo di una celebrità) può saturare CPU/rete di un singolo nodo Redis. Distribuiscila — replica la chiave su più nodi, o aggiungi una piccola cache locale in-process davanti a Redis per gli item più caldi.

## Prospettiva del colloquio

L'intervistatore vuole vederti pensare oltre "aggiungi Redis". Buono: cache-aside con TTL. Eccellente: nomini **protezione dallo stampede, strategia di invalidazione, gestione delle hot key, e cosa succede a un'interruzione della cache**. La trappola è assumere che la cache sia sempre attiva — se Redis muore e ogni miss ricade sul DB, ottieni una **cache-avalanche** che abbatte anche il DB.

## Compromessi e modalità di guasto

- **Staleness vs carico:** TTL corto = fresco ma più miss; TTL lungo = meno miss ma più stale. Regola per dato.
- **Cache avalanche:** molte chiavi che scadono insieme (stesso TTL) causano un picco di carico — aggiungi **jitter** ai TTL.
- **Consistenza:** cache e DB possono divergere; per letture money-critical, leggi dal DB o usa write-through.
- **Eviction di memoria:** sotto pressione Redis fa eviction per policy (LRU/LFU); una policy sbagliata scarta silenziosamente il tuo hot set.

Cache-aside vs read-through

TTL + invalidazione

Protezione dallo stampede e hot key

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate