Time Based Invalidation: TTL, Stale While Revalidate, and Expiry Strategies

TTL Basics
Time To Live (TTL) sets an expiration timestamp or duration counter. After time passes, the cache considers entries stale and either deletes them or marks them for refresh. TTL trades precision for simplicity: you will serve stale data during the window between an update and expiry, but gain predictable behavior without tracking every data change. For read heavy content with infrequent updates (blog posts, images), TTLs of 5-60 minutes achieve 95%+ hit rates. For frequently updated data (inventory, feeds), 1-10 second TTLs provide reasonable freshness.
Stale While Revalidate
When an entry expires, instead of blocking while fetching fresh data, immediately serve the stale value and trigger asynchronous background refresh. This keeps p95 and p99 latencies flat (under 200-500ms at CDN scale) during origin refreshes. Configure two windows: fresh period (serve directly from cache) and stale grace period (serve stale but trigger refresh). Example: 60s fresh with 30s stale grace means data older than 60s serves while refreshing, but older than 90s forces blocking fetch.
Jitter for Thundering Herd Prevention
When thousands of entries expire simultaneously (synchronized TTL from batch load), all clients hit origin concurrently, overwhelming the database. Adding 5-10% random jitter spreads expiration: TTL = base + random(0, 0.1 * base). With 1 hour base TTL and 6 minute jitter, 100,000 entries spread expiration over 6 minutes instead of hitting simultaneously.
Absolute vs Sliding Expiry
Absolute expiry uses fixed timestamp (item expires at 14:30 UTC). Sliding expiry resets duration on each access (item expires 5 minutes after last access). Absolute prevents indefinite caching of hot keys; sliding keeps frequently accessed data fresh but can cache rarely updated hot items forever. Choose based on workload: session tokens often use sliding (active users stay logged in), while content caches use absolute (even hot content refreshes periodically).
Key Trade-off: TTL only strategies inevitably serve stale data between updates and expiry. For correctness critical data (permissions, inventory, balances), supplement TTL with event driven invalidation.

💡 Key Takeaways

✓TTL bounds staleness by elapsed time rather than tracking changes. 5-60 minute TTLs for static content achieve 95%+ hit rates; 1-10 second TTLs for dynamic data.

✓Stale while revalidate serves expired values while refreshing in background, keeping p95/p99 latencies under 200-500ms during origin updates.

✓Add 5-10% jitter to prevent thundering herds: TTL = base + random(0, 0.1 * base) spreads synchronized expiration over minutes instead of simultaneous.

✓Absolute expiry (fixed timestamp) vs sliding expiry (reset on access): absolute prevents indefinite caching, sliding keeps hot data fresh.

📌 Interview Tips

1Explain stale while revalidate: 60s fresh + 30s stale grace means data 60-90s old serves immediately while refreshing in background.

2Jitter math: 100,000 entries with 1 hour TTL + 10% jitter spread expiration over 6 minutes instead of simultaneous spike.

3When asked about TTL selection: 5-60 min for blogs/images (static), 1-10s for inventory/feeds (dynamic), always with jitter.

← Back to Cache Invalidation Strategies Overview