TTL (time-to-live)
An expiry assigned to a cached entry; after it elapses the entry is evicted or considered stale. TTLs bound staleness and memory growth without explicit invalidation. The simplest staleness control.
- Almost always set a TTL on cache entries.
- Data tolerating bounded staleness.
- Data that must never be stale (use explicit invalidation).
- Permanent data (no TTL, but watch memory).
Definition
A TTL is a duration after which a cache entry expires. On read, expired entries are treated as misses (lazy expiry) or evicted by a background process. TTLs are set per key or per cache layer.
Why it exists
Without expiry, caches grow unbounded and serve stale data forever. TTLs give a hard upper bound on staleness and let memory self-limit, decoupling cache freshness from explicit invalidation.
How it works
Store value + expires_at. On read, if now > expires_at, treat as miss and (usually) refresh. Background eviction sweeps expired keys to reclaim memory. TTL jitter prevents synchronized expiry stampedes.
Scaling limits
Lazy expiry means stale entries occupy memory until read or swept. Very short TTLs cause high miss rates and DB load; very long TTLs risk staleness. Synchronized TTLs cause stampedes.
Cost shape
Negligible. The cost is the staleness/miss tradeoff you choose. Blow-ups: synchronized expiry causing stampedes and high churn.
Alternatives
- Explicit invalidation — Fresh on change, but requires wiring and can miss events.
- Versioned keys — Bump a version to invalidate, but complicates key management.
Failure modes
- Stampede on synchronized expiry.
- Stale data if TTL too long.
- Memory growth if expiry is lazy and rarely swept.