Strategie di caching: lazy loading e write-through

Inserire una cache tra l'applicazione e il database richiede una strategia di caching, ovvero un insieme di regole che stabilisce quando i dati vengono inseriti nella cache, quando vengono letti dalla cache e quando vengono rimossi. La scelta della strategia sbagliata può causare dati obsoleti (la cache restituisce valori non aggiornati), cache miss a cache fredda (la cache è vuota e ogni richiesta raggiunge il database) oppure un cache stampede (molte richieste simultanee per la stessa chiave mancante raggiungono contemporaneamente il database). Le due strategie fondamentali sono lazy loading e write-through.

Il lazy loading (chiamato anche cache-aside) è il pattern di caching più comune. L'applicazione controlla prima la cache. In caso di cache hit, i dati vengono restituiti direttamente dalla cache, seguendo il percorso più rapido. In caso di cache miss, l'applicazione recupera i dati dal database, scrive il risultato nella cache con un TTL e lo restituisce al chiamante. La cache viene popolata solo con i dati effettivamente richiesti, da cui il termine «lazy». La richiesta successiva per la stessa chiave troverà i dati nella cache.

Il lazy loading presenta tre vantaggi principali: vengono memorizzati nella cache solo i dati richiesti, quindi la cache non si riempie di dati che nessuno legge e la memoria viene utilizzata in modo efficiente. Una cache fredda non compromette il funzionamento dell'applicazione: in caso di cache miss, l'applicazione ricorre al database; pertanto, anche se ElastiCache viene riavviato o un nodo si guasta, l'applicazione continua a funzionare, seppure con una latenza maggiore. Infine, la cache è sempre eventualmente coerente con il database, perché i dati obsoleti scadono tramite TTL anche se alcuni aggiornamenti non sono stati intercettati.

Il lazy loading presenta tre svantaggi principali: i cache miss sono costosi: richiedono tre operazioni (controllo della cache, lettura del database e scrittura nella cache) rispetto a una sola in caso di hit, con una latenza maggiore per le richieste a cache fredda. Dati obsoleti: dopo un aggiornamento del database, la cache continua a restituire il vecchio valore fino alla scadenza del TTL o all'invalidazione esplicita della chiave, creando una finestra di incoerenza. Cache stampede: se una chiave molto richiesta scade, molte richieste simultanee registrano un cache miss e raggiungono contemporaneamente il database, rischiando di sovraccaricarlo.

Nella strategia write-through, ogni scrittura nel database viene eseguita contemporaneamente anche nella cache. L'applicazione scrive sia nella cache sia nel database come parte della stessa operazione, oppure il database attiva un aggiornamento della cache. La cache è quindi sempre sincronizzata con il database e non esiste una finestra in cui i dati siano obsoleti. Write-through garantisce che i dati presenti nella cache siano sempre aggiornati, rendendo le letture successive dei dati scritti di recente sempre dei cache hit.

Vantaggi di write-through: i dati nella cache sono sempre aggiornati, perché la cache viene aggiornata a ogni scrittura e non sono presenti dati obsoleti. Le letture sono sempre rapide: i dati più richiesti e aggiornati frequentemente si trovano sempre nella cache. Non si verificano cache stampede durante le letture: poiché i dati vengono precaricati prima di essere letti, non si verificano cache miss a cache fredda per i dati scritti di recente. Questa strategia è ideale per carichi di lavoro con molte letture e aggiornamenti frequenti in cui la freschezza dei dati è fondamentale, ad esempio cataloghi di prodotti, sistemi di prezzi o cache dei profili utente.

Svantaggi di write-through: penalizzazione delle scritture: ogni scrittura comporta due operazioni (database + cache), aumentando la latenza delle scritture. Inquinamento della cache: i dati vengono memorizzati nella cache anche se non saranno mai più letti, sprecando memoria. Il riavvio della cache produce una cache fredda: se il cluster della cache viene riavviato, tutti i dati scritti preventivamente vanno persi e la cache deve essere ripopolata tramite nuove scritture o mediante una procedura di riscaldamento. Combini write-through con un TTL per evitare la crescita illimitata di dati memorizzati nella cache ma raramente letti.

Nella pratica, molti sistemi di produzione combinano entrambe le strategie: utilizzano write-through per i dati aggiornati e letti frequentemente, come le sessioni utente o i prezzi correnti, e lazy loading per i dati aggiornati raramente ma letti frequentemente, come le descrizioni dei prodotti o il contenuto degli articoli. Imposti TTL appropriati per entrambe le strategie: alle chiavi write-through viene assegnato un TTL lungo, poiché i dati sono sempre aggiornati; alle chiavi caricate tramite lazy loading viene assegnato un TTL più breve, per limitare la finestra dei dati obsoleti. Questo approccio ibrido massimizza il tasso di cache hit riducendo al minimo l'obsolescenza.

Il Time-To-Live (TTL) dei dati memorizzati nella cache determina la durata massima della finestra dei dati obsoleti e l'occupazione di memoria della cache. Progetti i TTL in base alla frequenza di aggiornamento dei dati (i dati di sessione cambiano spesso → TTL breve; il contenuto statico cambia raramente → TTL lungo), alla tolleranza all'obsolescenza (prezzi finanziari → molto breve; testo di un post di blog → ore o giorni) e alla capacità di memoria della cache (memoria ridotta → TTL più breve per rimuovere più rapidamente i dati obsoleti). Imposti sempre un TTL: non memorizzi mai dati nella cache senza scadenza, altrimenti la cache finirà per riempirsi di dati obsoleti.

Anziché affidarsi esclusivamente alla scadenza del TTL, è possibile invalidare esplicitamente (eliminare) le chiavi della cache quando cambiano i dati sottostanti. In questo modo si elimina completamente la finestra dei dati obsoleti. Pattern comuni: delete-on-write (eliminare la chiave della cache dopo ogni aggiornamento del database; la lettura successiva la ripopola tramite lazy loading) e invalidazione guidata dagli eventi (DynamoDB Streams o l'acquisizione delle modifiche di RDS attivano una funzione Lambda che elimina le chiavi interessate). L'invalidazione della cache è uno dei problemi più complessi dei sistemi distribuiti; più semplice è la logica di invalidazione, più affidabile sarà la cache.

Un pattern meno comune ma potente è il write-behind (write-back): l'applicazione scrive solo nella cache, che scarica poi i dati nel database in modo asincrono e in background. Ciò consente scritture estremamente rapide (solo in memoria), al costo di una possibile perdita di dati se la cache si guasta prima dello scaricamento. Write-behind è adatto a scritture frequenti e ad alto volume quando i dati possono essere ricostruiti o sono accettabili perdite limitate, ad esempio per contatori di visualizzazioni, eventi di analisi o aggiornamenti dei punteggi di gioco. ElastiCache non supporta nativamente write-behind; deve essere implementato a livello applicativo.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) presentati in questa lezione.

In questa lezione ha appreso che il lazy loading popola la cache in caso di cache miss durante una lettura e utilizza la memoria in modo efficiente, ma può restituire dati obsoleti fino alla scadenza del TTL; write-through aggiorna la cache a ogni scrittura, evitando i dati obsoleti ma sprecando memoria per i dati non letti; infine, l'invalidazione esplicita elimina le chiavi della cache quando il database viene aggiornato, rimuovendo le finestre di dati obsoleti. Nella prossima lezione esamineremo l'archiviazione delle sessioni e i pattern delle classifiche con ElastiCache.