Che cos’è una cache distribuita e come gestirne i guasti?

Question

IT Interview Practice · Accepted Answer

**Una cache distribuita permette a più istanze applicative di riutilizzare dati attraverso la rete.** Serve a evitare lavoro costoso ripetuto, mantenendo regole chiare su aggiornamento e guasti.

Immagina tre istanze backend che leggono lo stesso catalogo prodotti. Con una cache interna al processo, ciascuna mantiene la propria copia. Con un servizio cache condiviso, un'istanza può inserire un valore riutilizzato dalle altre. Il servizio cache può a sua volta usare più nodi.

## 1. Decidi cosa memorizzare in sicurezza

Parti dal costo di produrre il dato e da quanto può essere obsoleto. Una descrizione di prodotto può tollerare un breve ritardo; il controllo finale delle scorte per un acquisto può richiedere dati autorevoli.

Definisci una chiave che identifichi il risultato completo, includendo tenant, lingua e altri input rilevanti. Altrimenti, una cache veloce può restituire i dati del cliente sbagliato. Mantieni il database autorevole per i record aziendali durevoli, perché i valori in cache possono sparire.

## 2. Segui il percorso di lettura prima di progettare gli aggiornamenti

Un approccio comune è cache-aside: l'applicazione controlla la cache, legge il database se il valore manca e memorizza il risultato con una scadenza, chiamata TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Riduce le letture ripetute del database quando molte richieste necessitano dello stesso valore. Aggiunge chiamate di rete e una dipendenza, quindi è utile solo se il lavoro evitato supera questi costi. Vedi [cache-aside con Redis](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Decidi come rendere visibili gli aggiornamenti

Per il catalogo, un punto di partenza pratico è confermare l'aggiornamento nel database e poi invalidare il prodotto in cache. Il lettore successivo lo ricarica. Rimane però una race condition: un lettore può prelevare il vecchio valore dal database prima del commit e inserirlo in cache dopo l'invalidazione.

Il TTL limita la durata di quella copia appena memorizzata; non garantisce che ogni lettura veda subito l'ultima scrittura. Se autorizzazioni, prezzi o saldi obsoleti violano le regole dell'operazione, verifica i dati autorevoli oppure progetta aggiornamenti che considerino le versioni con garanzie esplicite. Scegli la consistenza in base all'operazione aziendale, senza presumere che Redis la risolva.

## 4. Evita che un cache miss diventi un'interruzione

Quando scade una voce popolare, molti chiamanti possono leggere il database contemporaneamente. È un cache stampede. Un guasto della cache può creare lo stesso problema su molte voci.

- Accorpa caricamenti simultanei della stessa chiave per ridurre chi la ricostruisce; definisci se il coordinamento copre un processo o tutte le istanze.
- Varia le scadenze per evitare che molte voci scadano insieme. Distribuisce il rinnovo, ma non risolve ogni problema di chiave molto richiesta.
- Servi il valore precedente durante il rinnovo solo se il business consente dati obsoleti.
- Usa timeout brevi per la cache e limita il traffico di ripiego sul database. Rifiutare parte del lavoro può essere più sicuro che sovraccaricare il database facendo fallire tutte le richieste.

Prova deliberatamente questi percorsi. Un alto tasso di hit nel funzionamento normale dice poco sul comportamento quando la cache scompare.

## 5. Scala in base al vero collo di bottiglia

Lo sharding divide le chiavi tra nodi; la replica conserva copie per disponibilità o letture. Risolvono problemi diversi. Redis Cluster usa hash slot per la collocazione: aggiungere nodi non divide automaticamente il lavoro di una singola chiave molto richiesta. Vedi la [specifica Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Monitora hit rate, latenza, timeout, memoria, eviction e carico sul database. Un'eviction elimina un valore per gestire la memoria e può avvenire prima del TTL. Non considerare una voce in cache come storage durevole garantito per dati aziendali o lavoro accodato.

Per il catalogo, partirei da cache-aside con chiavi esplicite, una politica di aggiornamento e un ripiego protetto. Aggiungerei nodi solo dopo misure che dimostrino un problema di capacità realmente risolvibile distribuendo il carico. **Una buona cache spiega sia cosa succede quando il valore è presente sia quando manca o è sbagliato.**

1. Decidi cosa memorizzare in sicurezza

2. Segui il percorso di lettura prima di progettare gli aggiornamenti

3. Decidi come rendere visibili gli aggiornamenti

4. Evita che un cache miss diventi un'interruzione

5. Scala in base al vero collo di bottiglia

Domande correlate