TTL: ce este, durata de viață a cache-și cum funcționează

Ce este TTL?

TTL (Time To Live) — este un marcaj de timp sau un interval după care datele sunt considerate invalide. în contextul cache-uiri, TTL determină cât timp o înregistrare poate fi stocată în cache înainte de a fi necesară re-solicitarea din sursa originală. în protocoalele de rețea, TTL limitează durata de viață a unui pachet, prevenind rutarea infinită.

Valoarea TTL este exprimată întotdeauna în unități de timp: milisecunde, secunde, minute sau ore. După expirarea timpului stabilit, înregistrarea este fie ștearsă din cache, fie marcată ca stale (învechită). La următoarea cerere către o înregistrare învechită, sistemul poate returna datele învechite cu actualizare ulterioară (stale-while-revalidate) sau poate bloca cererea până la primirea datelor proaspete.

Alegerea TTL este întotdeauna un compromis între actualitatea datelor și performanță. Un TTL prea scurt (1–5 secunde) forțează aplicația să execute frecvent cereri de rețea, anulând beneficiile cache-uiri. Un TTL prea lung (ore/zile) crește riscul de a afișa utilizatorului informații învechite. Valoarea optimă depinde de tipul datelor: cursurile valutare — secunde, vremea — minute, versiunea API — ore.

TTL și invalidarea cache-ului

TTL este o invalidare pasivă: datele sunt șterse automat după expirarea timpului. Alternativa este invalidarea activă, în care sursa de date notifică cache-ul despre modificări (de exemplu, prin mesaje WebSocket sau notificări push). Invalidarea pasivă prin TTL este mai simplu de implementat, dar nu garantează actualitatea imediată. Invalidarea activă este mai complexă, dar permite menținerea datelor în stare actualizată fără întârzierile caracteristice TTL.

Cum funcționează TTL

Mecanismul TTL poate fi implementat în două moduri: expirare absolută (absolute expiration) și expirare relativă (relative expiration). în expirarea absolută, înregistrarea stochează un timp specific la care va deveni invalidă. în expirarea relativă — se înregistrează timpul de creare al înregistrării și TTL ca interval, iar verificarea se face prin calcularea creationTime + TTL > currentTime.

La fiecare cerere către cache, sistemul verifică TTL-ul fiecărei înregistrări. Dacă TTL a expirat, datele sunt șterse sau marcate ca stale, iar cererea este direcționată către sursă. Pentru optimizarea verificării TTL, se poate utiliza scheduled-cleanup (ștergerea periodică a tuturor înregistrărilor expirate) sau lazy-cleanup (ștergerea doar la accesarea înregistrării). Lazy-cleanup este mai eficient din punct de vedere al memoriei, deoarece nu necesită un fir de execuție fundal pentru scanarea întregului cache.

în sistemele distribuite, TTL este folosit și pentru rezolvarea automată a conflictelor. De exemplu, dacă două servere au scris simultan valori diferite pentru aceeași cheie, înregistrarea cu TTL mai tardiv poate fi considerată prioritară. Amazon DynamoDB utilizează TTL pentru ștergerea automată a înregistrărilor învechite în tabele — aceasta este o funcție încorporată care nu necesită gestionare manuală.

Strategii de citire a datelor învechite

Pentru a crește performanța după expirarea TTL, se aplică strategii de citire a datelor învechite. Stale-while-revalidate — returnează imediat datele învechite clientului și lansează simultan actualizarea în fundal. Stale-if-error — returnează datele învechite dacă sursa este temporar indisponibilă. Cache-Aside (Lazy Loading) — la o lipsă în cache, încarcă datele din sursă, le salvează în cache cu un nou TTL și abia apoi le returnează clientului. Fiecare strategie este aleasă în funcție de cerințele de consistență a datelor.

TTL în cacheuirea datelor

în aplicațiile mobile, TTL este mecanismul cheie de gestionare a cache-ului. Să examinăm scenariile principale în care TTL determină comportamentul aplicației și experiența utilizatorului.

Cacheuirea răspunsurilor HTTP

Protocolul HTTP oferă un mecanism TTL încorporat prin anteturile Cache-Control. Directiva max-age setează TTL în secunde: Cache-Control: public, max-age=3600 înseamnă că răspunsul poate fi cache-uit timp de 1 oră. Directivele suplimentare s-maxage (pentru cache-uri partajate, de ex. CDN) și stale-while-revalidate oferă un control mai fin. în cazul coincidenței TTL cu antetul expires, max-age are prioritate ca standard mai modern HTTP/1.1.

Cacheuirea imaginilor

Pentru imagini, TTL poate atinge câteva zile, deoarece conținutul se schimbă rar. Cu toate acestea, aplicațiile mobile folosesc adesea o abordare hibridă: TTL scurt pentru previzualizări (30 de minute — actualitatea cadrelor) și TTL lung pentru imagini la dimensiune completă (7 zile). Imaginile cu antetul HTTP Cache-Control: immutable nu ar trebui să fie re-solicitate deloc până la expirarea TTL — aceasta este o optimizare pentru resurse statice propusă în RFC 8246. Astfel de imagini sunt cache-uite la nivel de sistem de operare (URLCache, OkHttp Cache) fără implicarea aplicației.

TTL în protocoalele de rețea

în rețele, TTL este utilizat nu pentru cacheuire, ci pentru limitarea duratei de viață a pachetelor. Fiecare pachet IP conține un câmp TTL (8 biți) care este decrementat cu 1 de fiecare router. Când TTL ajunge la 0, pachetul este eliminat, iar expeditorului i se returnează un mesaj ICMP Time Exceeded. Aceasta previne rutarea infinită în cazul buclelor în rețea.

TTL în DNS

înregistrările DNS au un TTL care determină cât timp resolverul (de exemplu, cache-ul DNS al furnizorului de internet) poate stoca înregistrarea fără a solicita serverul autoritar. Valorile tipice: 300 de secunde (5 minute) pentru înregistrări cu modificări frecvente, 86400 de secunde (24 de ore) pentru domenii stabile. Serviciile CDN stabilesc adesea un TTL scăzut (60–300 de secunde) pentru redirecționarea rapidă a traficului în caz de defecțiuni, în timp ce domeniile statice pot avea un TTL de până la 7 zile. La migrarea serverului, se recomandă mai întâi reducerea TTL la 60 de secunde (cu 48 de ore înainte de migrare) pentru ca modificările să se răspândească rapid.

TTL în sesiuni și tokeni

în aplicațiile mobile, TTL este utilizat pentru gestionarea sesiunilor și a tokenilor de acces. Tokenii JWT (JSON Web Tokens) conțin câmpul exp (timpul de expirare), care este un timp Unix absolut de expirare. După expirare, tokenul de reîmprospătare (refresh token) este folosit pentru a obține un nou token de acces fără re-autentificare. TTL-ul tokenului de acces este de obicei de 1–24 de ore, iar al tokenului de reîmprospătare — de 7–30 de zile. Acesta este un echilibru între securitate (TTL scurt reduce riscul de scurgere) și experiența utilizatorului (TTL lung reduce frecvența re-autentificărilor).

Strategii de alegere a TTL

Alegerea TTL este o decizie inginerească ce depinde de tipul datelor, SLA-ul de actualitate și costul re-solicitării. Să examinăm strategiile principale.

TTL fix

Cea mai simplă abordare — toate înregistrările au același TTL. De exemplu, cacheuirea tuturor răspunsurilor API timp de 5 minute. Avantaj: simplitatea implementării și comportament previzibil. Dezavantaj: nu ia în considerare frecvența diferită de modificare a diferitelor tipuri de date. TTL fix este justificat pentru date omogene, unde toate înregistrările au aceeași „prospețime" — de exemplu, cursul criptomonedelor la o singură bursă.

TTL adaptiv

TTL se modifică dinamic în funcție de comportamentul datelor. De exemplu, dacă o înregistrare este rareori actualizată pe server, TTL crește; dacă este actualizată frecvent — scade. Implementarea poate utiliza anteturile răspunsurilor HTTP: antetul Age (câte secunde a petrecut deja răspunsul în cache) și antetul Date permit calcularea timpului rămas de viață. TTL-ul adaptiv oferă un hit-ratio mai bun, dar necesită logică suplimentară pe client.

TTL cu expirare probabilistică

Probabilistic Early Expiration (PEE) — o tehnică în care TTL este ales aleatoriu într-un interval dat. Aceasta previne „efectul de turmă" (thundering herd), când multe cereri expiră simultan și toți clienții se adresează simultan sursei. PEE este deosebit de utilă pentru CDN și cache-uri cu sarcină mare: în locul unui TTL unic de 300 de secunde, se utilizează o valoare aleatorie între 240 și 360 de secunde, ceea ce distribuie uniform sarcina pe sursă.

Exemple de cod TTL

Să examinăm implementarea unui cache cu TTL în Kotlin folosind expirarea absolută. Fiecare înregistrare stochează timpul de creare, iar la citire se verifică dacă TTL nu a expirat.

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) }
    }
}

Clasa Entry stochează valoarea și timpul de creare + TTL (expirare absolută). Metoda get verifică expirarea la fiecare accesare (lazy-cleanup) — înregistrările expirate sunt șterse doar la încercarea de accesare a lor. Metoda cleanup poate fi apelată periodic dintr-un fir de execuție fundal pentru ștergerea în bloc a tuturor înregistrărilor învechite. ConcurrentHashMap asigură siguranța firelor de execuție fără a bloca întregul cache.

Exemplu: TTL pentru cacheuirea răspunsurilor API pe iOS

în iOS, pentru cacheuirea cu TTL este convenabil să se utilizeze URLCache cu configurarea memoryCapacity și diskCapacity. Cu toate acestea, URLCache nu suportă TTL individual pentru diferite cereri. Să examinăm un înveliș personalizat NSCache cu suport 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
}

în această implementare, NSCache este utilizat ca un depozit sigur pentru firele de execuție. CacheEntry conține Data și expirationDate. La get, se verifică dacă timpul a expirat; dacă da — înregistrarea este ștearsă și se returnează nil. TTL este setat în secunde prin TimeInterval și poate fi diferit pentru fiecare URL: valorile tipice pentru răspunsurile API sunt 120 de secunde pentru conținut dinamic și 3600 pentru date statice.