Cache-invalidatie in mobiele ontwikkeling: strategieën en mechanismen

Wat is cache-invalidatie?

Cache-invalidatie — het proces van het annuleren of bijwerken van gecachte records die niet meer overeenkomen met de huidige staat van de gegevensbron. In tegenstelling tot het handmatig wissen van de volledige cache, werkt invalidatie gericht: alleen de gegevens waarvan de actualiteit in twijfel wordt getrokken.

De cache slaat kopieën van gegevens op voor snelle toegang. Na verloop van tijd kunnen de originele gegevens in de database of op de server veranderen — bijvoorbeeld de gebruiker heeft zijn profiel bijgewerkt of er is een nieuw bericht in de feed verschenen. Als de cache niet wordt geïnvalideerd, toont de app verouderde informatie, wat in mobiele apps leidt tot transactiefouten, onjuiste weergave en verlies van vertrouwen.

De grootste uitdaging van elke invalidatie — de bekende uitspraak „There are only two hard things in Computer Science: cache invalidation and naming things”. De complexiteit zit hem in het feit dat de cache niet weet wanneer de bron is veranderd, tenzij dit expliciet aan hem wordt gemeld.

Volgens Martin Kleppmann, auteur van het boek „Designing Data-Intensive Applications” (O’Reilly, 2017), vereist correcte invalidatie ofwel gecentraliseerde melding van wijzigingen, ofwel een mechanisme om de actualiteit bij elke lezing te controleren — een compromis tussen prestaties en consistentie.

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

Deze code toont een eenvoudige benadering: een record in de cache wordt als geldig beschouwd als de TTL niet is verlopen en de versie overeenkomt met de huidige in de bron. Het versiebeheermechanisme — een van de betrouwbare manieren om het tonen van verouderde gegevens te voorkomen.

Waarom is invalidatie nodig in mobiele apps

Actualiteit van gegevens — een belangrijke vereiste voor de meeste mobiele apps: sociale netwerken, messengers, bankdiensten, e-commerceplatforms. Een gebruiker die een onjuist saldo of oude berichten ziet, verliest het vertrouwen in de app.

Naast de gebruikerservaring lost invalidatie het probleem van het besparen van verkeer en batterij op. In plaats van periodiek volledig herladen van gegevens, kan de mobiele app alleen de gewijzigde records invalideren en ze gericht laden. Volgens Meta Engineering (2024) verminderde de implementatie van incrementele invalidatie in Facebook Lite het verkeersverbruik met 35% zonder verlies van actualiteit van inhoud.

Een ander belangrijk aspect — transactieconsistentie. In apps met een winkelwagen of reserveringen kan het gebruik van een verouderde cache leiden tot dubbele afschrijvingen of gegevensconflicten. Invalidatie na kritieke bewerkingen garandeert dat het volgende verzoek actuele gegevens leest.

Belangrijkste strategieën voor cache-invalidatie

TTL (Time-To-Live)

TTL — de eenvoudigste strategie, waarbij elk record in de cache een vaste levensduur krijgt. Na het verlopen van de TTL worden de gegevens als verouderd beschouwd en verwijderd bij de volgende lezing. TTL is ideaal voor gegevens die volgens een schema worden bijgewerkt — bijvoorbeeld weer of wisselkoersen. Nadeel: gegevens kunnen binnen het TTL-interval verouderd zijn.

Write-Through

Bij de Write-Through strategie gaat elke gegevenswijziging door de cache: het schrijven wordt gelijktijdig naar de cache en de bron uitgevoerd. Dit garandeert dat de cache altijd de huidige versie bevat. Nadeel — de schrijfvertraging neemt toe, omdat de bewerking niet wordt voltooid tot bevestiging van de bron. Write-Through is geschikt voor gegevens die cruciaal zijn voor consistentie: saldo, bestelstatus.

Write-Behind (Write-Back)

Write-Behind — asynchroon schrijven: gegevens komen onmiddellijk in de cache en worden later door een apart proces naar de bron geschreven. Dit biedt hoge schrijfprestaties, maar brengt het risico van gegevensverlies met zich mee bij een storing vóór synchronisatie. In mobiele apps wordt Write-Behind vaak gebruikt voor analyse, logs en niet-kritieke gebruikersacties.

Write-Invalidate

Write-Invalidate — in plaats van de cache bij te werken bij gegevenswijziging, wordt het bijbehorende record eenvoudigweg verwijderd (geïnvalideerd). De volgende lezing detecteert een cachemisser en laadt actuele gegevens uit de bron. Deze strategie is eenvoudig te implementeren en werkt goed wanneer leesverzoeken aanzienlijk talrijker zijn dan schrijfverzoeken.

De keuze van de strategie hangt af van wat prioriteit heeft voor het specifieke scenario: reactiesnelheid, consistentie of resourcebesparing. Hybride benaderingen — bijvoorbeeld TTL met Write-Invalidate bij ontvangst van een pushmelding — bieden een optimale balans.

Hoe invalidatie werkt op verschillende cacheniveaus

HTTP-cache — het eerste niveau aan de clientzijde. De browser of mobiele app slaat serverreacties op met Cache-Control en ETag-headers. Invalidatie vindt plaats bij ontvangst van een 304 Not Modified-antwoord of na het verlopen van max-age. ETag stelt de client in staat de actualiteit van een bron te controleren zonder het volledige antwoord te laden.

Applicatiecache — het tweede niveau, beheerd door code: in-memory caches (LRU, LruCache in Android) of schijf (SQLite, Room, Realm). Invalidatie wordt hier gecontroleerd door de ontwikkelaar. Volgens Android Developers (2025) vermindert correct gebruik van Room met Flow en invalidatie via triggers het aantal UI-hertekeningen met 40%.

Servercache — het derde niveau: Redis, Memcached, CDN. Op dit niveau wordt invalidatie uitgevoerd via TTL, DEL/PURGE-commando's of message brokers (RabbitMQ, Kafka). CDN-invalidatie — een aparte taak: vanwege de gedistribueerde aard van CDN kan een opschooncommando minuten duren om te verspreiden. Volgens Cloudflare (2024) duurt invalidatie via Purge by URL gemiddeld 5–15 seconden voor wereldwijde verspreiding.

Voor coördinatie van invalidatie op alle niveaus wordt een gecentraliseerde cacheservice of gebeurtenisbroker gebruikt. Bij gegevenswijziging publiceert de bron een gebeurtenis en elk niveau ontvangt een commando om specifieke sleutels te invalideren. Dit voorkomt de situatie waarin het ene niveau de gegevens al heeft bijgewerkt en een ander nog steeds de verouderde versie levert.

Veelvoorkomende fouten bij cache-invalidatie

Te lange TTL — de meest voorkomende fout. Ontwikkelaars stellen TTL “met reserve” in, wat ertoe leidt dat gebruikers uren of dagen verouderde gegevens zien. Oplossing: begin met een korte TTL (1–5 minuten) en verhoog deze pas na het meten van de werkelijke behoefte.

Invalidatie van de volledige cache bij één wijziging — een typisch probleem in microservice-architectuur. Eén gebruiker heeft zijn avatar bijgewerkt en de cache wordt voor iedereen geïnvalideerd. Bij een groot aantal gebruikers veroorzaakt dit het Cache Stampede effect — een lawine van verzoeken naar de bron. Oplossing: invalideer alleen de sleutel van de specifieke gebruiker, niet de volledige cache.

Ontbreken van invalidatie bij schrijffouten — als het schrijven naar de bron mislukt en de cache al is bijgewerkt, komt de app in een inconsistente toestand. Oplossing: tweefaseninvalidatie — eerst de cache wissen, dan naar de bron schrijven en de invalidatie bij fout terugdraaien.

Negeren van de gedistribueerde aard — in een clusteromgeving betekent invalidatie op één knooppunt niet dat andere knooppunten het commando hebben ontvangen. Zonder een gebeurtenisbroker blijft een deel van de servers verouderde gegevens leveren. Redis Pub/Sub of Apache Kafka lossen dit probleem op door invalidatiegebeurtenissen te verspreiden.

Hoe kies je een invalidatiestrategie

Bepaal de vereisten voor actualiteit — hoe kritiek is het dat gegevens “nu meteen” actueel zijn. Voor een nieuwsfeed is een vertraging van 1–2 minuten acceptabel (TTL). Voor een saldo is vertraging onaanvaardbaar (Write-Through).

Beoordeel de frequentie van wijzigingen — gegevens die eenmaal per dag worden bijgewerkt (productcatalogus, stedengids) werken uitstekend met TTL. Gegevens die tientallen keren per seconde veranderen (online status, wisselkoersen) vereisen push-invalidatie via WebSocket of Firebase Cloud Messaging.

Houd rekening met de kosten van het lezen van de bron — als de bron een dure SQL-query over 10 tabellen is of een externe API met limieten, is het beter om agressieve caching met lange TTL te gebruiken, maar verouderde gegevens te compenseren met push-invalidatie. Als lezen goedkoop is (in-memory lookup), kan korte TTL en Write-Invalidate worden gebruikt.

Volgens Google I/O (2025) is het typische patroon voor een mobiele app — Stale-While-Revalidate: de gebruiker ziet onmiddellijk gecachte gegevens en de app controleert op de achtergrond hun actualiteit en werkt ze bij. Dit combineert responssnelheid en actualiteit zonder compromissen. De HTTP-header Cache-Control met de richtlijn stale-while-revalidate wordt ondersteund vanaf Android 10 en iOS 13.