TTL: Was es ist, Cache-Lebensdauer und wie es funktioniert

Was ist TTL?

TTL (Time To Live) ist ein Zeitstempel oder Intervall, nach dem Daten als ungültig betrachtet werden. Im Kontext des Cachings bestimmt TTL, wie lange ein Datensatz im Cache gespeichert werden kann, bevor er erneut von der Quelle angefordert werden muss. In Netzwerkprotokollen begrenzt TTL die Lebensdauer eines Pakets und verhindert Endlos-Routing.

Der TTL-Wert wird immer in Zeiteinheiten ausgedrückt: Millisekunden, Sekunden, Minuten oder Stunden. Nach Ablauf der eingestellten Zeit wird der Datensatz entweder aus dem Cache gelöscht oder als veraltet markiert. Bei der nächsten Anfrage an einen veralteten Datensatz kann das System entweder die veralteten Daten mit einer späteren Aktualisierung (Stale-While-Revalidate) zurückgeben oder die Anfrage blockieren, bis neue Daten vorliegen.

Die Wahl der TTL ist immer ein Kompromiss zwischen Datenaktualität und Leistung. Eine zu kurze TTL (1–5 Sekunden) zwingt die Anwendung zu häufigen Netzwerkanfragen und macht den Vorteil des Cachings zunichte. Eine zu lange TTL (Stunden/Tage) erhöht das Risiko, dem Benutzer veraltete Informationen anzuzeigen. Der optimale Wert hängt vom Datentyp ab: Wechselkurse — Sekunden, Wetter — Minuten, API-Version — Stunden.

TTL und Cache-Invalidierung

TTL ist eine passive Invalidierung: Daten werden nach einer Zeitspanne automatisch entfernt. Die Alternative ist die aktive Invalidierung, bei der die Datenquelle den Cache über Änderungen informiert (z. B. über WebSocket-Nachrichten oder Push-Benachrichtigungen). Die passive Invalidierung über TTL ist einfacher zu implementieren, garantiert aber keine sofortige Aktualität. Die aktive Invalidierung ist komplexer, ermöglicht aber, Daten ohne die für TTL typischen Verzögerungen aktuell zu halten.

Wie TTL funktioniert

Der TTL-Mechanismus kann auf zwei Arten implementiert werden: absolute Ablaufzeit (Absolute Expiration) und relative Ablaufzeit (Relative Expiration). Bei der absoluten Ablaufzeit speichert der Datensatz die genaue Zeit, zu der er ungültig wird. Bei der relativen Ablaufzeit werden die Erstellungszeit des Datensatzes und die TTL als Intervall aufgezeichnet, und die Überprüfung erfolgt durch Berechnung von creationTime + TTL > currentTime.

Bei jeder Anfrage an den Cache überprüft das System die TTL jedes Datensatzes. Wenn die TTL abgelaufen ist, werden die Daten gelöscht oder als veraltet markiert, und die Anfrage wird an die Quelle weitergeleitet. Zur Optimierung der TTL-Überprüfung kann eine geplante Bereinigung (periodisches Löschen aller abgelaufenen Datensätze) oder eine faule Bereinigung (Löschen nur beim Zugriff auf den Datensatz) verwendet werden. Die faule Bereinigung ist speichereffizienter, da sie keinen Hintergrundthread zum Durchsuchen des gesamten Caches benötigt.

In verteilten Systemen wird TTL auch zur automatischen Konfliktlösung verwendet. Wenn beispielsweise zwei Server gleichzeitig unterschiedliche Werte für denselben Schlüssel schreiben, kann der Datensatz mit der späteren TTL als prioritär betrachtet werden. Amazon DynamoDB verwendet TTL zum automatischen Löschen veralteter Datensätze in Tabellen — dies ist eine integrierte Funktion, die keine manuelle Verwaltung erfordert.

Strategien für veraltete Lesevorgänge

Zur Leistungssteigerung bei Ablauf der TTL werden Strategien für veraltete Lesevorgänge eingesetzt. Stale-While-Revalidate — veraltete Daten sofort an den Client zurückgeben und gleichzeitig eine Hintergrundaktualisierung starten. Stale-If-Error — veraltete Daten zurückgeben, wenn die Quelle vorübergehend nicht verfügbar ist. Cache-Aside (Lazy Loading) — bei einem Cache-Fehler die Daten aus der Quelle laden, mit einer neuen TTL im Cache speichern und erst dann an den Client zurückgeben. Jede Strategie wird basierend auf den Datenkonsistenzanforderungen ausgewählt.

TTL beim Zwischenspeichern von Daten

In mobilen Anwendungen ist TTL ein Schlüsselmechanismus für die Cache-Verwaltung. Betrachten wir die wichtigsten Szenarien, in denen TTL das Anwendungsverhalten und die Benutzererfahrung bestimmt.

Zwischenspeichern von HTTP-Antworten

Das HTTP-Protokoll bietet einen eingebauten TTL-Mechanismus über die Cache-Control-Header. Die Direktive max-age setzt die TTL in Sekunden: Cache-Control: public, max-age=3600 bedeutet, dass die Antwort für 1 Stunde zwischengespeichert werden kann. Zusätzliche Direktiven s-maxage (für gemeinsame Caches, z. B. CDN) und stale-while-revalidate ermöglichen eine feinere Steuerung. Wenn die TTL mit dem Expires-Header übereinstimmt, hat max-age als modernerer HTTP/1.1-Standard Priorität.

Zwischenspeichern von Bildern

Bei Bildern kann die TTL mehrere Tage betragen, da sich der Inhalt selten ändert. Mobile Anwendungen verwenden jedoch oft einen hybriden Ansatz: eine kurze TTL für Vorschaubilder (30 Minuten — Bildaktualität) und eine lange TTL für Vollbilder (7 Tage). Bilder mit dem HTTP-Header Cache-Control: immutable sollten bis zum Ablauf der TTL nicht erneut angefordert werden — dies ist eine Optimierung für statische Ressourcen, die in RFC 8246 vorgeschlagen wurde. Solche Bilder werden auf Betriebssystemebene (URLCache, OkHttp Cache) ohne Beteiligung der Anwendung zwischengespeichert.

TTL in Netzwerkprotokollen

In Netzwerken wird TTL nicht zum Caching, sondern zur Begrenzung der Lebensdauer von Paketen verwendet. Jedes IP-Paket enthält ein TTL-Feld (8 Bit), das von jedem Router um 1 verringert wird. Wenn TTL 0 erreicht, wird das Paket verworfen und der Absender erhält eine ICMP Time Exceeded-Nachricht. Dies verhindert Endlos-Routing bei Netzwerkschleifen.

TTL im DNS

DNS-Einträge haben eine TTL, die bestimmt, wie lange ein Resolver (z. B. ISP-DNS-Cache) den Eintrag ohne Anfrage beim autoritativen Server speichern kann. Typische Werte: 300 Sekunden (5 Minuten) für Einträge mit häufigen Änderungen, 86400 Sekunden (24 Stunden) für stabile Domains. CDN-Dienste setzen oft eine niedrige TTL (60–300 Sekunden) für schnelle Traffic-Umleitung bei Ausfällen, während statische Domains eine TTL von bis zu 7 Tagen haben können. Bei einer Server-Migration wird empfohlen, die TTL zunächst auf 60 Sekunden zu senken (48 Stunden vor der Migration), damit sich Änderungen schnell verbreiten.

TTL in Sitzungen und Token

In mobilen Anwendungen wird TTL zur Verwaltung von Sitzungen und Zugriffstoken verwendet. JWT-Token (JSON Web Tokens) enthalten ein exp-Feld (Ablaufzeit), das die absolute Unix-Ablaufzeit darstellt. Nach Ablauf wird ein Aktualisierungstoken verwendet, um ohne erneute Authentifizierung ein neues Zugriffstoken zu erhalten. Die TTL des Zugriffstokens beträgt normalerweise 1–24 Stunden, die TTL des Aktualisierungstokens 7–30 Tage. Dies ist ein Gleichgewicht zwischen Sicherheit (kurze TTL reduziert das Risiko von Lecks) und UX (lange TTL reduziert die Häufigkeit erneuter Anmeldungen).

TTL-Auswahlstrategien

Die Wahl der TTL ist eine technische Entscheidung, die vom Datentyp, der Aktualitäts-SLA und den Kosten einer erneuten Anfrage abhängt. Betrachten wir die wichtigsten Strategien.

Feste TTL

Der einfachste Ansatz — alle Datensätze haben dieselbe TTL. Beispiel: Alle API-Antworten für 5 Minuten zwischenspeichern. Vorteil: Einfachheit der Implementierung und vorhersagbares Verhalten. Nachteil: Berücksichtigt nicht die unterschiedliche Änderungshäufigkeit verschiedener Datentypen. Die feste TTL ist für homogene Daten gerechtfertigt, bei denen alle Datensätze dieselbe „Aktualität“ haben — zum Beispiel Kryptowährungskurse an einer Börse.

Adaptive TTL

TTL ändert sich dynamisch basierend auf dem Datenverhalten. Wenn ein Datensatz beispielsweise auf dem Server selten aktualisiert wird, erhöht sich die TTL; wenn er häufig aktualisiert wird, verringert sie sich. Die Implementierung kann HTTP-Antwort-Header verwenden: der Age-Header (wie viele Sekunden die Antwort bereits im Cache war) und der Date-Header ermöglichen die Berechnung der verbleibenden Lebensdauer. Adaptive TTL bietet eine bessere Trefferquote, erfordert aber zusätzliche Logik auf dem Client.

TTL mit probabilistischem Ablauf

Probabilistic Early Expiration (PEE) — eine Technik, bei der TTL zufällig innerhalb eines bestimmten Bereichs gewählt wird. Dies verhindert den „Thundering Herd“-Effekt, bei dem viele Anfragen gleichzeitig ablaufen und alle Clients gleichzeitig auf die Quelle zugreifen. PEE ist besonders nützlich für CDNs und stark ausgelastete Caches: Anstelle einer einzelnen TTL von 300 Sekunden wird ein zufälliger Wert zwischen 240 und 360 Sekunden verwendet, der die Last auf die Quelle gleichmäßig verteilt.

TTL-Codebeispiele

Betrachten wir eine Cache-Implementierung mit TTL in Kotlin unter Verwendung des absoluten Ablaufs. Jeder Datensatz speichert seine Erstellungszeit, und beim Lesen wird geprüft, ob die TTL abgelaufen ist.

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

Die Entry-Klasse speichert den Wert und die Erstellungszeit + TTL (absoluter Ablauf). Die get-Methode prüft bei jedem Zugriff den Ablauf (faule Bereinigung) — abgelaufene Datensätze werden nur gelöscht, wenn versucht wird, auf sie zuzugreifen. Die cleanup-Methode kann periodisch von einem Hintergrundthread aufgerufen werden, um alle veralteten Datensätze stapelweise zu löschen. ConcurrentHashMap bietet Thread-Sicherheit, ohne den gesamten Cache zu sperren.

Beispiel: TTL für das Zwischenspeichern von API-Antworten unter iOS

Unter iOS ist es praktisch, URLCache mit den Einstellungen memoryCapacity und diskCapacity für das Caching mit TTL zu verwenden. URLCache unterstützt jedoch keine individuelle TTL für verschiedene Anfragen. Betrachten wir einen benutzerdefinierten NSCache-Wrapper mit TTL-Unterstützung.

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 dieser Implementierung wird NSCache als threadsicherer Speicher verwendet. CacheEntry enthält Data und expirationDate. Beim Aufruf von get wird geprüft, ob die Zeit abgelaufen ist; wenn ja, wird der Datensatz gelöscht und nil zurückgegeben. Die TTL wird in Sekunden über TimeInterval festgelegt und kann für jede URL unterschiedlich sein: typische Werte für API-Antworten sind 120 Sekunden für dynamische Inhalte und 3600 für statische Daten.