Invalidazione della cache nello sviluppo mobile: strategie e meccanismi

Cos'è l'invalidazione della cache?

Invalidazione della cache è il processo di invalidamento o aggiornamento delle voci nella cache che non corrispondono più allo stato corrente della fonte dati. A differenza della pulizia manuale dell'intera cache, l'invalidazione funziona selettivamente: solo i dati la cui pertinenza è dubbia.

La cache memorizza copie dei dati per un accesso rapido. Con il tempo, i dati originali nel database o sul server possono cambiare — ad esempio, un utente ha aggiornato il proprio profilo o è apparso un nuovo post nel feed. Se la cache non viene invalidata, l'app mostrerà informazioni obsolete, che nelle app mobili porta a errori di transazione, visualizzazione errata e perdita di fiducia.

La difficoltà principale di qualsiasi invalidazione è il noto detto “There are only two hard things in Computer Science: cache invalidation and naming things”. La complessità risiede nel fatto che la cache non sa quando la fonte è cambiata a meno che non venga esplicitamente notificata.

Secondo Martin Kleppmann, autore di “Designing Data-Intensive Applications” (O'Reilly, 2017), un'invalidazione corretta richiede una notifica centralizzata dei cambiamenti o un meccanismo per verificare la pertinenza a ogni lettura — un compromesso tra performance e coerenza.

data class CacheEntryT(
    val data: T,
    val expiresAt: Long,
    val version: Int = 0
)

fun CacheT.isValid(key: String): Boolean =
    get(key)?.let { it.expiresAt > currentTimeMillis() && it.version == currentVersion(key) } ?: false

Questo codice mostra un approccio semplice: una voce nella cache è considerata valida se il TTL non è scaduto e la versione corrisponde a quella corrente nella fonte. Il meccanismo di versionamento è uno dei modi affidabili per evitare di mostrare dati obsoleti.

Perché l'invalidazione è necessaria nelle app mobili

Attualità dei dati è un requisito fondamentale per la maggior parte delle applicazioni mobili: social network, messaggeri, servizi bancari, piattaforme e-commerce. Un utente che vede un saldo del conto errato o messaggi vecchi perde fiducia nell'app.

Oltre all'esperienza utente, l'invalidazione risparmia traffico e batteria. Invece di ricaricare periodicamente tutti i dati, un'app mobile può invalidare solo le voci modificate e caricarli selettivamente. Secondo Meta Engineering (2024), l'implementazione dell'invalidazione incrementale in Facebook Lite ha ridotto il consumo di traffico del 35% senza perdere l'attualità del contenuto.

Un altro aspetto importante è la coerenza delle transazioni. Nelle app con carrello della spesa o sistema di prenotazione, l'uso di una cache obsoleta può portare a doppi addebiti o conflitti di dati. L'invalidazione dopo operazioni critiche garantisce che la richiesta successiva legga dati freschi.

Principali strategie di invalidazione della cache

TTL (Time-To-Live)

TTL è la strategia più semplice, dove ogni voce nella cache riceve una durata di vita fissa. Quando il TTL scade, i dati sono considerati obsoleti e vengono rimossi alla prossima lettura. TTL è ideale per dati aggiornati secondo un programma — ad esempio, meteo o tassi di cambio. Svantaggio: i dati potrebbero non essere aggiornati all'interno dell'intervallo TTL.

Write-Through

Con la strategia Write-Through, ogni modifica dei dati passa attraverso la cache: la scrittura viene eseguita simultaneamente nella cache e nella fonte. Ciò garantisce che la cache contenga sempre la versione corrente. Lo svantaggio è una maggiore latenza di scrittura, poiché l'operazione non si completa finché la fonte non conferma. Write-Through è adatto per dati critici per la coerenza: saldo del conto, stato dell'ordine.

Write-Behind (Write-Back)

Write-Behind è una scrittura asincrona: i dati vanno immediatamente nella cache e vengono scritti nella fonte successivamente da un processo separato. Ciò offre alte performance di scrittura ma comporta il rischio di perdita di dati in caso di guasto prima della sincronizzazione. Nelle app mobili, Write-Behind è spesso utilizzato per analisi, log e azioni utente non critiche.

Write-Invalidate

Write-Invalidate — invece di aggiornare la cache quando i dati cambiano, rimuove semplicemente (invalida) la voce corrispondente. La prossima lettura rileverà un cache miss e caricherà dati freschi dalla fonte. Questa strategia è semplice da implementare e funziona bene quando le richieste di lettura superano significativamente quelle di scrittura.

La scelta della strategia dipende da ciò che è più importante per uno scenario specifico: velocità di risposta, coerenza o risparmio di risorse. Gli approcci ibridi — ad esempio, TTL con Write-Invalidate alla ricezione di una notifica push — offrono un equilibrio ottimale.

Come funziona l'invalidazione a diversi livelli di cache

Cache HTTP è il primo livello lato client. Il browser o l'app mobile memorizza le risposte del server con le intestazioni Cache-Control ed ETag. L'invalidazione avviene alla ricezione di una risposta 304 Not Modified o alla scadenza di max-age. ETag permette al client di verificare l'attualità della risorsa senza scaricare la risposta completa.

Cache dell'app è il secondo livello, gestito dal codice: cache in memoria (LRU, LruCache in Android) o su disco (SQLite, Room, Realm). L'invalidazione qui è controllata dallo sviluppatore. Secondo Android Developers (2025), l'uso corretto di Room con Flow e l'invalidazione basata su trigger riduce i ridisegni dell'interfaccia del 40%.

Cache del server è il terzo livello: Redis, Memcached, CDN. A questo livello, l'invalidazione viene effettuata tramite TTL, comandi DEL/PURGE o broker di messaggi (RabbitMQ, Kafka). L'invalidazione CDN è una sfida separata: a causa della natura distribuita della CDN, un comando di purga può impiegare minuti per propagarsi globalmente. Secondo Cloudflare (2024), l'invalidazione tramite Purge by URL richiede in media 5–15 secondi per la propagazione globale.

Per coordinare l'invalidazione a tutti i livelli, viene utilizzato un servizio di cache centralizzato o un broker di eventi. Quando i dati cambiano, la fonte pubblica un evento e ogni livello riceve un comando per invalidare chiavi specifiche. Ciò impedisce una situazione in cui un livello ha già aggiornato i dati mentre un altro continua a servire la versione obsoleta.

Errori comuni nell'invalidazione della cache

TTL troppo lungo è l'errore più comune. Gli sviluppatori impostano TTL con un margine, facendo sì che gli utenti vedano dati obsoleti per ore o giorni. Soluzione: iniziare con un TTL breve (1–5 minuti) e aumentarlo solo dopo aver misurato il bisogno reale.

Invalidare l'intera cache per un singolo cambiamento è un problema tipico nell'architettura a microservizi. Un utente aggiorna il proprio avatar e la cache viene invalidata per tutti. Con un gran numero di utenti, ciò causa un Cache Stampede — un'ondata di richieste alla fonte. Soluzione: invalidare solo la chiave dell'utente specifico, non la cache condivisa.

Mancata invalidazione in caso di errori di scrittura — se la scrittura nella fonte fallisce ma la cache è già stata aggiornata, l'app si trova in uno stato incoerente. Soluzione: invalidazione in due fasi — prima pulire la cache, poi scrivere nella fonte e annullare l'invalidazione in caso di errore.

Ignorare la natura distribuita — in un ambiente cluster, l'invalidazione su un nodo non significa che altri nodi abbiano ricevuto il comando. Senza un broker di eventi, alcuni server continueranno a servire dati obsoleti. Redis Pub/Sub o Apache Kafka risolvono questo problema trasmettendo eventi di invalidazione.

Come scegliere una strategia di invalidazione

Determina i requisiti di attualità — quanto è critico che i dati siano aggiornati “proprio ora.” Per un feed di notizie, un ritardo di 1–2 minuti è accettabile (TTL). Per il saldo di un conto, il ritardo è inaccettabile (Write-Through).

Valuta la frequenza dei cambiamenti — i dati che vengono aggiornati una volta al giorno (catalogo prodotti, elenco città) funzionano bene con TTL. I dati che cambiano decine di volte al secondo (stati online, tassi di cambio) richiedono invalidazione push tramite WebSocket o Firebase Cloud Messaging.

Considera il costo di lettura della fonte — se la fonte è una costosa query SQL su 10 tabelle o un'API esterna con limiti, usa una memorizzazione nella cache aggressiva con TTL lungo, ma compensa i dati obsoleti con invalidazione push. Se la lettura è economica (ricerca in memoria), usa un TTL breve e Write-Invalidate.

Secondo Google I/O (2025), il pattern tipico per le app mobili è Stale-While-Revalidate: l'utente vede immediatamente i dati nella cache mentre l'app ne verifica l'attualità in background e li aggiorna. Ciò combina velocità di risposta e attualità senza compromessi. L'intestazione HTTP Cache-Control con la direttiva stale-while-revalidate è supportata a partire da Android 10 e iOS 13.