Invalidarea cache-ului în dezvoltarea mobilă: strategii și mecanisme

Ce este invalidarea cache-ului?

Invalidarea cache-ului — procesul de anulare sau actualizare a înregistrărilor din cache care nu mai corespund stării actuale a sursei de date. Spre deosebire de curățarea manuală a întregului cache, invalidarea funcționează punctual: doar acele date a căror actualitate este pusă la îndoială.

Cache-ul stochează copii ale datelor pentru acces rapid. În timp, datele originale din bază de date sau de pe server se pot schimba — de exemplu, utilizatorul și-a actualizat profilul sau a apărut o nouă postare în feed. Dacă cache-ul nu este invalidat, aplicația va afișa informații învechite, ceea ce în aplicațiile mobile duce la erori de tranzacții, afișare incorectă și pierdere a încrederii.

Principala dificultate a oricărei invalidări — celebra zicală „There are only two hard things in Computer Science: cache invalidation and naming things”. Complexitatea constă în faptul că cache-ul nu știe când sursa s-a schimbat, dacă nu i se comunică în mod explicit.

Conform Martin Kleppmann, autorul cărții „Designing Data-Intensive Applications” (O’Reilly, 2017), invalidarea corectă necesită fie notificare centralizată a modificărilor, fie un mecanism de verificare a actualității la fiecare citire — un compromis între performanță și consistență.

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

Acest cod arată o abordare simplă: înregistrarea din cache este considerată validă dacă TTL nu a expirat și versiunea coincide cu cea actuală din sursă. Mecanismul de versionare — una dintre modalitățile sigure de a evita afișarea datelor învechite.

De ce este necesară invalidarea în aplicațiile mobile

Actualitatea datelor — cerința cheie pentru majoritatea aplicațiilor mobile: rețele sociale, mesagerie, servicii bancare, platforme e-commerce. Un utilizator care vede un sold incorect al contului sau mesaje vechi își pierde încrederea în aplicație.

Pe lângă experiența utilizatorului, invalidarea rezolvă problema economisirii traficului și a bateriei. În locul reîncărcării complete periodice a datelor, aplicația mobilă poate invalida doar înregistrările modificate și le poate încărca punctual. Conform Meta Engineering (2024), implementarea invalidării incrementale în Facebook Lite a redus consumul de trafic cu 35% fără pierderea actualității conținutului.

Un alt aspect important — consistența tranzacțiilor. În aplicațiile cu coș de cumpărături sau rezervări, utilizarea unui cache învechit poate duce la dublări de plăți sau conflicte de date. Invalidarea după operațiuni critice garantează că următoarea cerere va citi date proaspete.

Principalele strategii de invalidare a cache-ului

TTL (Time-To-Live)

TTL — cea mai simplă strategie, în care fiecare înregistrare din cache primește o durată de viață fixă. După expirarea TTL, datele sunt considerate învechite și eliminate la următoarea citire. TTL este ideal pentru datele care se actualizează conform unui program — de exemplu, vremea sau cursul valutar. Dezavantaj: datele pot fi neactualizate în intervalul TTL.

Write-Through

În strategia Write-Through, fiecare modificare a datelor trece prin cache: scrierea se execută simultan în cache și în sursă. Aceasta garantează că cache-ul conține întotdeauna versiunea actuală. Dezavantajul — întârzierea la scriere crește, deoarece operațiunea nu se finalizează până la confirmarea din partea sursei. Write-Through este potrivit pentru date critice pentru consistență: soldul contului, statusul comenzii.

Write-Behind (Write-Back)

Write-Behind — scriere asincronă: datele ajung imediat în cache, iar în sursă sunt scrise mai târziu printr-un proces separat. Aceasta oferă performanță ridicată la scriere, dar implică riscul pierderii datelor în caz de defecțiune înainte de sincronizare. În aplicațiile mobile, Write-Behind este adesea folosit pentru analitică, loguri și acțiuni necritice ale utilizatorului.

Write-Invalidate

Write-Invalidate — în loc să actualizeze cache-ul la modificarea datelor, pur și simplu șterge (invalidează) înregistrarea corespunzătoare. Următoarea citire va detecta lipsa din cache și va încărca date proaspete din sursă. Această strategie este simplu de implementat și funcționează bine atunci când cererile de citire sunt semnificativ mai multe decât cele de scriere.

Alegerea strategiei depinde de ceea ce este prioritar pentru scenariul specific: viteza de răspuns, consistența sau economisirea resurselor. Abordările hibride — de exemplu, TTL cu Write-Invalidate la primirea unei notificări push — oferă un echilibru optim.

Cum funcționează invalidarea la diferite niveluri de cache

Cache HTTP — primul nivel pe partea clientului. Browserul sau aplicația mobilă stochează răspunsurile serverului cu antetele Cache-Control și ETag. Invalidarea are loc la primirea unui răspuns 304 Not Modified sau la expirarea max-age. ETag permite clientului să verifice actualitatea resursei fără a încărca răspunsul complet.

Cache-ul aplicației — al doilea nivel, gestionat de cod: cache-uri în memorie (LRU, LruCache în Android) sau pe disc (SQLite, Room, Realm). Invalidarea aici este controlată de dezvoltator. Conform Android Developers (2025), utilizarea corectă a Room cu Flow și invalidarea prin triggeri reduce numărul de re-randomizări UI cu 40%.

Cache-ul serverului — al treilea nivel: Redis, Memcached, CDN. La acest nivel, invalidarea se realizează prin TTL, comenzi DEL/PURGE sau brokeri de mesaje (RabbitMQ, Kafka). Invalidarea CDN — o sarcină separată: datorită naturii distribuite a CDN-ului, comanda de ștergere poate dura minute pentru a se propaga. Conform Cloudflare (2024), invalidarea prin Purge by URL durează în medie 5–15 secunde pentru răspândirea globală.

Pentru coordonarea invalidării la toate nivelurile se utilizează un serviciu centralizat de cache sau un broker de evenimente. La modificarea datelor, sursa publică un eveniment, iar fiecare nivel primește comanda de invalidare a cheilor specifice. Aceasta previne situația în care un nivel a actualizat deja datele, iar altul continuă să livreze versiunea învechită.

Erori tipice la invalidarea cache-ului

TTL prea lung — cea mai frecventă eroare. Dezvoltatorii setează TTL „cu rezervă”, ceea ce duce la faptul că utilizatorii văd date învechite ore sau zile. Soluție: începeți cu un TTL scurt (1–5 minute) și creșteți-l doar după măsurarea necesității reale.

Invalidarea întregului cache la o singură modificare — problemă tipică în arhitectura microserviciilor. Un utilizator și-a actualizat avatarul, iar cache-ul este invalidat pentru toți. La un număr mare de utilizatori, aceasta provoacă efectul de Cache Stampede — o avalanșă de cereri către sursă. Soluție: invalidați doar cheia utilizatorului specific, nu întregul cache.

Lipsa invalidării la erori de scriere — dacă scrierea în sursă a eșuat, iar cache-ul a fost deja actualizat, aplicația ajunge într-o stare inconsistentă. Soluție: invalidare în două faze — mai întâi curățați cache-ul, apoi scrieți în sursă și anulați invalidarea la eroare.

Ignorarea naturii distribuite — într-un mediu cluster, invalidarea pe un nod nu înseamnă că celelalte noduri au primit comanda. Fără un broker de evenimente, o parte dintre servere vor continua să livreze date învechite. Redis Pub/Sub sau Apache Kafka rezolvă această problemă prin difuzarea evenimentelor de invalidare.

Cum să alegeți strategia de invalidare

Determinați cerințele de actualitate — cât de critic este ca datele să fie proaspete „acum imediat”. Pentru fluxul de știri, o întârziere de 1–2 minute este acceptabilă (TTL). Pentru soldul contului — întârzierea este inacceptabilă (Write-Through).

Evaluați frecvența modificărilor — datele care se actualizează o dată pe zi (catalogul produselor, ghidul orașelor) funcționează excelent cu TTL. Datele care se schimbă de zeci de ori pe secundă (statusurile online, cursurile valutare) necesită invalidare push prin WebSocket sau Firebase Cloud Messaging.

Luați în considerare costul citirii sursei — dacă sursa este o interogare SQL costisitoare pe 10 tabele sau un API extern cu limite, este mai bine să utilizați cache agresiv cu TTL lung, dar să compensați datele învechite cu invalidare push. Dacă citirea este ieftină (in-memory lookup), puteți utiliza TTL scurt și Write-Invalidate.

Conform Google I/O (2025), modelul tipic pentru o aplicație mobilă — Stale-While-Revalidate: utilizatorul vede instantaneu datele din cache, iar aplicația în fundal verifică actualitatea lor și le actualizează. Aceasta combină viteza de răspuns și actualitatea fără compromisuri. Antetul HTTP Cache-Control cu directiva stale-while-revalidate este suportat începând cu Android 10 și iOS 13.