Cache Daten, die teuer zu erzeugen sind, häufig gelesen werden und sich selten ändern — das ist, wo sich Caching am meisten auszahlt. Das TTL (time to live) ist ein Kompromiss zwischen Aktualität (wie aktuell die Daten sein müssen) und Staleness Toleranz (wie falsch sie wie lange sein dürfen).
Ein guter Cache-Kandidat schneidet in allen drei Punkten gut ab:
Cachen Sie nicht billig-zu-berechnen, write-heavy oder pro-Benutzer-geheime Daten, deren Aktualität exakt sein muss (z. B. Kontostände zum Zeitpunkt einer Transaktion).
Staleness tolerance → TTL:
config / static reference data → long (hours to days)
product listings, article body → medium (minutes)
prices, stock, leaderboards → short (seconds)
must always be exact → don't cache, or use explicit invalidation
Für Korrektheit bei Daten, die sich unvorhersehbar ändern, kombinieren Sie TTL mit expliziter Invalidierung: write-through oder delete-on-write, damit der Cache in dem Moment geleert wird, in dem sich die Quelle ändert, anstatt auf den Ablauf zu warten.
on update(record):
db.save(record)
cache.delete(key(record)) // invalidate now, don't serve stale until TTL
hit ratio = hits / (hits + misses)
high (>90%) → cache is doing its job
low → TTL too short, keys too granular, or data not cacheable
Überwachen Sie die Cache Hit Ratio, um TTLs zu optimieren: Eine niedrige Quote bedeutet, dass Sie kaum cachen; eine hohe Quote mit Beschwerden über veraltete Daten bedeutet, dass TTLs zu lang sind.
Die richtige Entscheidung, was zu cachen und welches TTL zu wählen, ist der Kern des effizienten Cachings. Wenn Sie die falschen Dinge cachen, fügen Sie Komplexität ohne Gewinn hinzu; wenn Sie TTLs zu lange setzen, servieren Sie veraltete Daten; wenn Sie sie zu kurz setzen, verlieren Sie den Vorteil. Die Verwendung von Staleness Toleranz zur Auswahl von TTLs, das Hinzufügen expliziter Invalidierung für Korrektheit und die Überwachung der Hit Ratio geben Ihnen eine prinzipiengesteuerte, messbare Methode zum Cachen.