TTL: wat is het, levensduur van cache en hoe het werkt

Wat is TTL?

TTL (Time To Live) — is een tijdmarkering of interval waarna gegevens als ongeldig worden beschouwd. In de context van caching bepaalt TTL hoe lang een record in de cache kan worden bewaard voordat het opnieuw moet worden opgevraagd bij de oorspronkelijke bron. In netwerkprotocollen beperkt TTL de levensduur van een pakket en voorkomt het oneindige routering.

De TTL-waarde wordt altijd uitgedrukt in tijdseenheden: milliseconden, seconden, minuten of uren. Na het verstrijken van de ingestelde tijd wordt het record verwijderd uit de cache of gemarkeerd als stale (verouderd). Bij het volgende verzoek aan een verouderd record kan het systeem de verouderde gegevens teruggeven met een latere actualisatie (stale-while-revalidate) of het verzoek blokkeren totdat er nieuwe gegevens zijn.

TTL kiezen is altijd een compromis tussen de actualiteit van gegevens en prestaties. Een te korte TTL (1-5 seconden) dwingt de applicatie om frequent netwerkverzoeken uit te voeren, waardoor het voordeel van caching teniet wordt gedaan. Een te lange TTL (uren/dagen) verhoogt het risico dat de gebruiker verouderde informatie te zien krijgt. De optimale waarde hangt af van het type gegevens: wisselkoersen — seconden, weer — minuten, API-versie — uren.

TTL en cache-invalidatie

TTL is passieve invalidatie: gegevens worden automatisch verwijderd na het verstrijken van de tijd. Het alternatief is actieve invalidatie, waarbij de gegevensbron de cache op de hoogte stelt van wijzigingen (bijvoorbeeld via WebSocket-berichten of pushmeldingen). Passieve invalidatie via TTL is eenvoudiger te implementeren, maar garandeert geen onmiddellijke actualiteit. Actieve invalidatie is complexer, maar maakt het mogelijk gegevens actueel te houden zonder de vertragingen die kenmerkend zijn voor TTL.

Hoe werkt TTL

Het TTL-mechanisme kan op twee manieren worden geïmplementeerd: absolute vervaldatum (absolute expiration) en relatieve vervaldatum (relative expiration). Bij absolute vervaldatum slaat het record een specifiek tijdstip op waarop het ongeldig wordt. Bij relatieve vervaldatum wordt de aanmaaktijd van het record en TTL als interval geregistreerd, en de controle wordt uitgevoerd door creationTime + TTL > currentTime te berekenen.

Bij elk verzoek aan de cache controleert het systeem de TTL van elk record. Als de TTL is verlopen, worden de gegevens verwijderd of gemarkeerd als stale, en wordt het verzoek naar de bron geleid. Voor optimalisatie van de TTL-controle kan scheduled-cleanup (periodiek verwijderen van alle verlopen records) of lazy-cleanup (alleen verwijderen bij toegang tot het record) worden gebruikt. Lazy-cleanup is geheugenefficiënter omdat het geen achtergrondthread nodig heeft om de hele cache te scannen.

In gedistribueerde systemen wordt TTL ook gebruikt voor het automatisch oplossen van conflicten. Als bijvoorbeeld twee servers tegelijkertijd verschillende waarden voor dezelfde sleutel hebben geschreven, kan het record met een latere TTL als prioritair worden beschouwd. Amazon DynamoDB gebruikt TTL voor het automatisch verwijderen van verouderde records in tabellen — dit is een ingebouwde functie die geen handmatig beheer vereist.

Strategieën voor verouderde leesbewerkingen

Om de prestaties na het verlopen van TTL te verbeteren, worden strategieën voor verouderde leesbewerkingen toegepast. Stale-while-revalidate — geef onmiddellijk verouderde gegevens terug aan de client en start tegelijkertijd een achtergrondupdate. Stale-if-error — geef verouderde gegevens terug als de bron tijdelijk niet beschikbaar is. Cache-Aside (Lazy Loading) — bij een cachemisser laadt u de gegevens uit de bron, slaat u deze in de cache op met een nieuwe TTL en geeft u ze pas daarna aan de client terug. Elke strategie wordt gekozen op basis van de vereisten voor gegevensconsistentie.

TTL bij het cachen van gegevens

In mobiele applicaties is TTL het belangrijkste mechanisme voor cachebeheer. Laten we de belangrijkste scenarioën bekijken waarin TTL het gedrag van de applicatie en de gebruikerservaring bepaalt.

Cachen van HTTP-antwoorden

Het HTTP-protocol biedt een ingebouwd TTL-mechanisme via de headers Cache-Control. De richtlijn max-age stelt TTL in seconden in: Cache-Control: public, max-age=3600 betekent dat het antwoord 1 uur kan worden gecached. Aanvullende richtlijnen s-maxage (voor gedeelde caches, zoals CDN) en stale-while-revalidate bieden een fijnmazigere controle. In geval van overlap van TTL met de expires-header heeft max-age prioriteit als modernere HTTP/1.1-standaard.

Cachen van afbeeldingen

Voor afbeeldingen kan TTL enkele dagen bedragen, omdat de inhoud zelden verandert. Mobiele applicaties gebruiken echter vaak een hybride benadering: een korte TTL voor miniaturen (30 minuten — actualiteit van frames) en een lange voor afbeeldingen op volledige grootte (7 dagen). Afbeeldingen met de HTTP-header Cache-Control: immutable mogen helemaal niet opnieuw worden aangevraagd tot het verlopen van de TTL — dit is een optimalisatie voor statische bronnen voorgesteld in RFC 8246. Dergelijke afbeeldingen worden gecached op het niveau van het besturingssysteem (URLCache, OkHttp Cache) zonder tussenkomst van de applicatie.

TTL in netwerkprotocollen

In netwerken wordt TTL niet gebruikt voor caching, maar voor het beperken van de levensduur van pakketten. Elk IP-pakket bevat een TTL-veld (8 bits) dat met 1 wordt verminderd door elke router. Wanneer TTL 0 bereikt, wordt het pakket weggegooid en wordt een ICMP Time Exceeded-bericht naar de afzender teruggestuurd. Dit voorkomt oneindige routering bij lussen in het netwerk.

TTL in DNS

DNS-records hebben een TTL die bepaalt hoe lang de resolver (bijvoorbeeld de DNS-cache van de ISP) het record kan bewaren zonder de autoritatieve server te raadplegen. Typische waarden: 300 seconden (5 minuten) voor records met frequente wijzigingen, 86400 seconden (24 uur) voor stabiele domeinen. CDN-diensten stellen vaak een lage TTL in (60-300 seconden) voor snelle omleiding van verkeer bij storingen, terwijl statische domeinen een TTL tot 7 dagen kunnen hebben. Bij servermigratie wordt aanbevolen eerst de TTL te verlagen naar 60 seconden (48 uur voor de migratie), zodat wijzigingen zich snel verspreiden.

TTL in sessies en tokens

In mobiele applicaties wordt TTL gebruikt voor het beheren van sessies en toegangstokens. JWT-tokens (JSON Web Tokens) bevatten het veld exp (vervaltijd), dat een absolute Unix-vervaltijd is. Na het verlopen wordt de vernieuwingstoken (refresh token) gebruikt om een nieuwe toegangstoken te verkrijgen zonder herhaalde authenticatie. De TTL van een toegangstoken bedraagt meestal 1-24 uur, die van een vernieuwingstoken 7-30 dagen. Dit is een balans tussen beveiliging (korte TTL verlaagt het risico op lekkage) en gebruikerservaring (lange TTL vermindert de frequentie van herhaalde aanmeldingen).

Strategieën voor TTL-keuze

De keuze van TTL is een technische beslissing die afhangt van het type gegevens, de SLA voor actualiteit en de kosten van een herhaald verzoek. Laten we de belangrijkste strategieën bekijken.

Vaste TTL

De eenvoudigste benadering — alle records hebben dezelfde TTL. Bijvoorbeeld alle API-antwoorden 5 minuten cachen. Voordeel: eenvoudige implementatie en voorspelbaar gedrag. Nadeel: houdt geen rekening met de verschillende wijzigingsfrequentie van verschillende gegevenstypen. Vaste TTL is gerechtvaardigd voor homogene gegevens waarbij alle records dezelfde ‛versheid“ hebben — bijvoorbeeld de koers van cryptovaluta op één beurs.

Adaptieve TTL

TTL verandert dynamisch afhankelijk van het gedrag van de gegevens. Als een record bijvoorbeeld zelden op de server wordt bijgewerkt, neemt de TTL toe; als het vaak wordt bijgewerkt — neemt deze af. De implementatie kan gebruikmaken van HTTP-antwoordheaders: de header Age (hoeveel seconden het antwoord al in de cache heeft doorgebracht) en de header Date maken het mogelijk de resterende levensduur te berekenen. Adaptieve TTL geeft een betere hit-ratio, maar vereist extra logica aan de clientzijde.

TTL met probabilistisch verlopen

Probabilistic Early Expiration (PEE) — een techniek waarbij TTL willekeurig wordt gekozen in een bepaald bereik. Dit voorkomt het ‛kudde-effect“ (thundering herd), wanneer veel verzoeken tegelijkertijd verlopen en alle clients tegelijkertijd een beroep doen op de bron. PEE is vooral nuttig voor CDN en zwaarbelaste caches: in plaats van een uniforme TTL van 300 seconden wordt een willekeurige waarde tussen 240 en 360 seconden gebruikt, wat de belasting op de bron gelijkmatig verdeelt.

TTL-codevoorbeelden

Laten we de implementatie van een cache met TTL in Kotlin bekijken met behulp van absolute vervaldatum. Elke record slaat de aanmaaktijd op en bij het lezen wordt gecontroleerd of de TTL is verlopen.

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

De klasse Entry slaat de waarde en de aanmaaktijd + TTL op (absolute vervaldatum). De methode get controleert bij elke toegang op verlopen (lazy-cleanup) — verlopen records worden alleen verwijderd bij een poging tot toegang. De methode cleanup kan periodiek worden aangeroepen vanuit een achtergrondthread voor het batchgewijs verwijderen van alle verouderde records. ConcurrentHashMap zorgt voor threadveiligheid zonder de hele cache te blokkeren.

Voorbeeld: TTL voor het cachen van API-antwoorden op iOS

In iOS is het handig om URLCache te gebruiken met de instellingen memoryCapacity en diskCapacity voor caching met TTL. URLCache ondersteunt echter geen individuele TTL voor verschillende verzoeken. Laten we een aangepaste wrapper van NSCache met TTL-ondersteuning bekijken.

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 deze implementatie wordt NSCache gebruikt als een threadveilige opslag. CacheEntry bevat Data en expirationDate. Bij get wordt gecontroleerd of de tijd is verlopen; zo ja, dan wordt het record verwijderd en wordt nil geretourneerd. TTL wordt ingesteld in seconden via TimeInterval en kan voor elke URL verschillend zijn: typische waarden voor API-antwoorden zijn 120 seconden voor dynamische inhoud en 3600 voor statische gegevens.