TTL: cos’è, durata della cache e come funziona

Cos’è TTL?

TTL (Time To Live) è un timestamp o un intervallo dopo il quale i dati sono considerati non validi. Nel contesto della memorizzazione nella cache, TTL determina per quanto tempo un record può essere conservato nella cache prima di dover essere richiesto nuovamente alla fonte. Nei protocolli di rete, TTL limita la durata di vita di un pacchetto, prevenendo il routing infinito.

Il valore TTL è sempre espresso in unità di tempo: millisecondi, secondi, minuti o ore. Dopo la scadenza del tempo impostato, il record viene eliminato dalla cache o contrassegnato come obsoleto. Alla successiva richiesta a un record obsoleto, il sistema può restituire i dati obsoleti con un aggiornamento successivo (stale-while-revalidate) o bloccare la richiesta fino all’ottenimento di dati freschi.

Scegliere il TTL è sempre un compromesso tra la freschezza dei dati e le performance. Un TTL troppo breve (1–5 secondi) costringe l’applicazione a effettuare richieste di rete frequenti, annullando il vantaggio della cache. Un TTL troppo lungo (ore/giorni) aumenta il rischio di mostrare informazioni obsolete all’utente. Il valore ottimale dipende dal tipo di dati: tassi di cambio — secondi, meteo — minuti, versione API — ore.

TTL e invalidazione della cache

TTL è invalidazione passiva: i dati vengono rimossi automaticamente dopo un periodo di tempo. L’alternativa è l’invalidazione attiva, dove la fonte dei dati notifica la cache dei cambiamenti (ad esempio, tramite messaggi WebSocket o notifiche push). L’invalidazione passiva tramite TTL è più semplice da implementare ma non garantisce freschezza istantanea. L’invalidazione attiva è più complessa ma consente di mantenere i dati aggiornati senza i ritardi tipici del TTL.

Come funziona TTL

Il meccanismo TTL può essere implementato in due modi: scadenza assoluta (absolute expiration) e scadenza relativa (relative expiration). Con la scadenza assoluta, il record memorizza l’ora specifica in cui diventerà non valido. Con la scadenza relativa, vengono registrati l’ora di creazione del record e il TTL come intervallo, e il controllo viene effettuato calcolando creationTime + TTL > currentTime.

Ad ogni richiesta alla cache, il sistema controlla il TTL di ciascun record. Se il TTL è scaduto, i dati vengono eliminati o contrassegnati come obsoleti, e la richiesta viene inoltrata alla fonte. Per ottimizzare il controllo del TTL, è possibile utilizzare una pulizia programmata (eliminazione periodica di tutti i record scaduti) o una pulizia pigra (eliminazione solo quando si accede al record). La pulizia pigra è più efficiente in termini di memoria perché non richiede un thread in background per scansionare l’intera cache.

Nei sistemi distribuiti, TTL viene utilizzato anche per la risoluzione automatica dei conflitti. Ad esempio, se due server scrivono contemporaneamente valori diversi per la stessa chiave, il record con TTL successivo può essere considerato prioritario. Amazon DynamoDB utilizza TTL per l’eliminazione automatica dei record obsoleti nelle tabelle — questa è una funzionalità incorporata che non richiede gestione manuale.

Strategie di lettura obsoleta

Per migliorare le performance alla scadenza del TTL, vengono utilizzate strategie di lettura obsoleta. Stale-while-revalidate — restituire immediatamente i dati obsoleti al client e avviare contemporaneamente un aggiornamento in background. Stale-if-error — restituire dati obsoleti se la fonte è temporaneamente non disponibile. Cache-Aside (Lazy Loading) — in caso di mancata corrispondenza nella cache, caricare i dati dalla fonte, salvarli nella cache con un nuovo TTL e solo poi restituirli al client. Ogni strategia viene scelta in base ai requisiti di coerenza dei dati.

TTL nella memorizzazione nella cache dei dati

Nelle applicazioni mobili, TTL è un meccanismo chiave per la gestione della cache. Vediamo i principali scenari in cui TTL determina il comportamento dell’applicazione e l’esperienza utente.

Memorizzazione nella cache delle risposte HTTP

Il protocollo HTTP fornisce un meccanismo TTL incorporato attraverso le intestazioni Cache-Control. La direttiva max-age imposta il TTL in secondi: Cache-Control: public, max-age=3600 significa che la risposta può essere memorizzata nella cache per 1 ora. Direttive aggiuntive s-maxage (per cache condivise, es.: CDN) e stale-while-revalidate forniscono un controllo più preciso. Quando TTL coincide con l’intestazione expires, max-age ha priorità come standard HTTP/1.1 più moderno.

Memorizzazione nella cache delle immagini

Per le immagini, TTL può raggiungere diversi giorni poiché il contenuto raramente cambia. Tuttavia, le applicazioni mobili utilizzano spesso un approccio ibrido: un TTL breve per le anteprime (30 minuti — freschezza dei fotogrammi) e un TTL lungo per le immagini a grandezza naturale (7 giorni). Le immagini con intestazione HTTP Cache-Control: immutable non dovrebbero essere richieste nuovamente fino alla scadenza del TTL — questa è un’ottimizzazione per le risorse statiche proposta nella RFC 8246. Tali immagini vengono memorizzate nella cache a livello di sistema operativo (URLCache, OkHttp Cache) senza il coinvolgimento dell’applicazione.

TTL nei protocolli di rete

Nelle reti, TTL non viene utilizzato per la memorizzazione nella cache ma per limitare la durata di vita dei pacchetti. Ogni pacchetto IP contiene un campo TTL (8 bit), che viene decrementato di 1 da ogni router. Quando TTL raggiunge 0, il pacchetto viene scartato e il mittente riceve un messaggio ICMP Time Exceeded. Ciò impedisce il routing infinito durante i loop di rete.

TTL nel DNS

I record DNS hanno un TTL che determina per quanto tempo un resolver (ad esempio, la cache DNS del provider) può conservare il record senza interrogare il server autorevole. Valori tipici: 300 secondi (5 minuti) per record con modifiche frequenti, 86400 secondi (24 ore) per domini stabili. I servizi CDN spesso impostano un TTL basso (60–300 secondi) per un rapido reindirizzamento del traffico durante i guasti, mentre i domini statici possono avere un TTL fino a 7 giorni. Durante la migrazione di un server, si consiglia di ridurre prima il TTL a 60 secondi (48 ore prima della migrazione) in modo che le modifiche si propaghino rapidamente.

TTL in sessioni e token

Nelle applicazioni mobili, TTL viene utilizzato per gestire sessioni e token di accesso. I token JWT (JSON Web Tokens) contengono un campo exp (tempo di scadenza), che è il tempo di scadenza Unix assoluto. Dopo la scadenza, un token di aggiornamento viene utilizzato per ottenere un nuovo token di accesso senza ri-autenticazione. Il TTL del token di accesso è solitamente di 1–24 ore, il TTL del token di aggiornamento è di 7–30 giorni. Questo è un equilibrio tra sicurezza (TTL breve riduce il rischio di perdita) e UX (TTL lungo riduce la frequenza dei nuovi accessi).

Strategie di selezione TTL

Scegliere il TTL è una decisione ingegneristica che dipende dal tipo di dati, dallo SLA di freschezza e dal costo di una nuova richiesta. Consideriamo le principali strategie.

TTL fisso

L’approccio più semplice — tutti i record hanno lo stesso TTL. Ad esempio, memorizzare nella cache tutte le risposte API per 5 minuti. Vantaggio: semplicità di implementazione e comportamento prevedibile. Svantaggio: non tiene conto della diversa frequenza di cambiamento dei diversi tipi di dati. Il TTL fisso è giustificato per dati omogenei dove tutti i record hanno la stessa “freschezza” — ad esempio, i tassi di criptovalute su un unico exchange.

TTL adattivo

TTL cambia dinamicamente in base al comportamento dei dati. Ad esempio, se un record viene raramente aggiornato sul server, TTL aumenta; se viene aggiornato frequentemente, diminuisce. L’implementazione può utilizzare le intestazioni di risposta HTTP: l’intestazione Age (quanti secondi la risposta è già stata nella cache) e l’intestazione Date consentono di calcolare la durata di vita rimanente. TTL adattivo offre un miglior rapporto di hit ma richiede logica aggiuntiva sul client.

TTL con scadenza probabilistica

Probabilistic Early Expiration (PEE) — una tecnica in cui TTL viene scelto casualmente entro un intervallo specificato. Ciò previene l’effetto “mandria al galoppo” (thundering herd), dove molte richieste scadono contemporaneamente e tutti i client accedono alla fonte nello stesso momento. PEE è particolarmente utile per CDN e cache ad alto carico: invece di un singolo TTL di 300 secondi, viene utilizzato un valore casuale da 240 a 360 secondi, distribuendo il carico sulla fonte in modo uniforme.

Esempi di codice TTL

Vediamo un’implementazione di cache con TTL in Kotlin utilizzando la scadenza assoluta. Ogni record memorizza il suo tempo di creazione e, durante la lettura, viene verificato se il TTL è scaduto.

class TtlCache<K, V>(
    private val defaultTtlMs: Long = 300000L
) {
    private data class Entry<V>(
        val value: V,
        val createdAt: Long = System.currentTimeMillis()
    )

    private val map = ConcurrentHashMap<K, Entry<V>>()

    fun get(key: K): V? {
        val entry = map[key] ?: return null
        if (isExpired(entry)) {
            map.remove(key)
            return null
        }
        return entry.value
    }

    fun put(key: K, value: V, ttlMs: Long = defaultTtlMs) {
        map[key] = Entry(value, createdAt = System.currentTimeMillis() + ttlMs)
    }

    private fun isExpired(entry: Entry<*>): Boolean {
        return System.currentTimeMillis() > entry.createdAt
    }

    fun cleanup() {
        map.entries.removeIf { isExpired(it.value) }
    }
}

La classe Entry memorizza il valore e il tempo di creazione + TTL (scadenza assoluta). Il metodo get controlla la scadenza ad ogni accesso (pulizia pigra) — i record scaduti vengono eliminati solo quando si tenta di accedervi. Il metodo cleanup può essere chiamato periodicamente da un thread in background per eliminare in batch tutti i record obsoleti. ConcurrentHashMap fornisce thread safety senza bloccare l’intera cache.

Esempio: TTL per la memorizzazione nella cache delle risposte API su iOS

Su iOS, è conveniente utilizzare URLCache con le impostazioni memoryCapacity e diskCapacity per la memorizzazione nella cache con TTL. Tuttavia, URLCache non supporta TTL individuale per diverse richieste. Consideriamo un wrapper personalizzato di NSCache con supporto TTL.

final class ApiResponseCache {
    private var cache = NSCache<NSString, CacheEntry>()

    func getResponse(for url: URL) -> Data? {
        guard let entry = cache.object(forKey: url.absoluteString as NSString)
            else { return nil }
        guard entry.expirationDate > Date() else {
            cache.removeObject(forKey: url.absoluteString as NSString)
            return nil
        }
        return entry.data
    }

    func storeResponse(data: Data, for url: URL, ttl: TimeInterval) {
        let entry = CacheEntry(data: data, expirationDate: Date().addingTimeInterval(ttl))
        cache.setObject(entry, forKey: url.absoluteString as NSString)
    }
}

final class CacheEntry: NSObject {
    let data: Data
    let expirationDate: Date
}

In questa implementazione, NSCache viene utilizzato come archivio thread-safe. CacheEntry contiene Data e expirationDate. Quando get viene chiamato, verifica se il tempo è scaduto; se sì, il record viene eliminato e viene restituito nil. TTL viene impostato in secondi tramite TimeInterval e può essere diverso per ogni URL: i valori tipici per le risposte API sono 120 secondi per contenuti dinamici e 3600 per dati statici.