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

Time based invalidation uses timestamps or duration counters to decide when cached data becomes invalid, independent of whether the underlying data actually changed. The most common form is Time To Live (TTL): when you cache an entry, you set an expiration timestamp (absolute expiry) or a duration counter (sliding expiry). After that time passes, the cache considers the entry stale and either deletes it or marks it for refresh. This approach trades precision for simplicity and stability because you will inevitably serve stale data during the window between an update and expiry, but you gain predictable cache behavior and avoid the distributed systems complexity of tracking every data change.

Stale while revalidate is a sophisticated time based pattern that improves on naive TTL expiry. When an entry expires, instead of blocking the request while fetching fresh data, you immediately serve the stale cached value and trigger an asynchronous background refresh to update the cache. This keeps response latencies low and stable (your 95th and 99th percentile latencies stay flat) while still refreshing data regularly. You configure two time windows: the fresh period (serve directly from cache) and the stale grace period (serve stale but trigger refresh). For example, a 60 second fresh period with a 30 second stale window means data older than 60 seconds will be served while refreshing, but data older than 90 seconds forces a blocking fetch. Modern CDN providers use this extensively: Cloudflare and Fastly maintain p95 response latencies under 200 to 500 milliseconds during origin refreshes by serving stale content with grace periods.

The critical numbers for TTL selection depend on your read/write ratio and staleness tolerance. For read heavy content with infrequent updates like blog posts or product images, TTLs of 5 to 60 minutes reduce origin load dramatically (95% plus cache hit rates) while staleness rarely matters. For frequently updated data like inventory counts or social media feeds, short TTLs of 1 to 10 seconds provide reasonable freshness, though you may need event driven invalidation as a supplement for correctness critical updates. Adding small random jitter (5 to 10 percent of TTL) prevents synchronized expiry that causes thundering herds when many entries expire simultaneously.

💡 Key Takeaways

•Time To Live (TTL) bounds staleness by elapsed time rather than tracking actual data changes, trading guaranteed freshness for operational simplicity and predictable cache behavior without complex invalidation infrastructure

•Stale while revalidate pattern serves expired cached values immediately while asynchronously refreshing in background, keeping p95 and p99 latencies flat (200 to 500 milliseconds at CDN scale) during origin updates

•TTL selection numbers: 5 to 60 minute TTLs work for read heavy static content (blogs, images) achieving 95% plus cache hit rates; 1 to 10 second TTLs suit frequently updated data (feeds, counters) where some staleness is acceptable

•Add 5 to 10 percent random jitter to TTL values to prevent thundering herds from synchronized expiry when thousands of entries expire at the same moment and all clients simultaneously hit origin

•Absolute expiry (fixed timestamp) versus sliding expiry (reset on access) have different behaviors: absolute prevents indefinite caching of hot keys, sliding keeps frequently accessed data fresh but can cache rarely updated hot items forever

•Failure mode: TTL only strategies inevitably serve stale data between updates and expiry, making them unsuitable alone for correctness critical data like permissions, inventory, or financial balances without event driven supplements

📌 Examples

A CDN caching product images with 3600 second (1 hour) TTL plus 1800 second (30 minute) stale while revalidate grace period achieves consistent sub 100 millisecond response times even during origin refreshes, while a product update becomes visible within 90 minutes worst case

Meta's TAO system uses short TTLs (seconds to low minutes) for many social graph objects as a safety net, even though most invalidations are event driven, ensuring that missed invalidation events self heal within the TTL window rather than serving stale data indefinitely

An API gateway caching authentication tokens with 300 second (5 minute) sliding expiry: frequently used tokens stay cached and fast, while inactive tokens naturally expire, but adding 15 second jitter (285 to 315 second range) prevents all tokens from one login batch expiring simultaneously

← Back to Cache Invalidation Strategies Overview