TTL jitter and explicit stale windows

A cache can stop returning an expired entry before background cleanup reclaims its storage. Conversely, retaining stale bytes for revalidation does not make them eligible for an ordinary fresh hit. Use an absolute age or expiry rule appropriate to the product rather than extending freshness on every access by accident. A sliding inactivity timeout can keep a hot value resident indefinitely and therefore does not impose the same source-age bound as an absolute freshness lifetime.

A TTL measured from fill time bounds time since that fill only. If the origin read already came from a stale replica, total source age includes that prior lag. Network and clock uncertainty may matter for strict real-time promises. Permission or deletion changes can require active invalidation or a stronger source check rather than waiting for a general content TTL. State these cases separately instead of advertising one freshness number for every kind of data.

A stale-while-revalidate policy can let an eligible request reuse an old response while a refresh proceeds, but must define the maximum additional window and the outcome when refresh fails or never starts. HTTP extensions have precise conditions; application caches need equally clear rules. Stale-if-error is another permission with a different trigger. Neither should quietly replace a requirement to check current authorization or to honor an explicit prohibition on stale reuse.

Adding positive jitter to a nominal TTL increases its maximum unless the nominal value was already budgeted below the limit. Adding a stale window increases the possible serving age further. Repeatedly resetting the original fill timestamp during failed refresh attempts can make an apparently bounded policy unbounded. Preserve trustworthy age metadata and validate the final serving decision against it. Track stale responses separately from fresh hits so an improved hit ratio cannot hide an expanded freshness compromise.

Independent jitter reduces synchronized expiry in expectation, but random clusters and correlated fills remain possible. A large deployment may seed generators badly or use coarse timer resolution, accidentally aligning expirations again. Refresh cost can vary by key, so even an equal count per second may produce uneven origin load. Combine jitter with coalescing, bounded concurrency, and a capacity-aware fallback rather than relying on randomness as the sole overload protection.

The probability lab is a limited independent-expiry-bin illustration. If TTLs are uniform over a fifteen-second interval, one chosen one-second bin has probability 1/15, which the control cannot represent exactly. Instead Reset and set both p=0.2, n=20 for five equal bins; predict four entries in one selected bin on average, then inspect the exact distribution. This fixed binomial model does not schedule TTLs, measure age, or serve stale data. Play highlights possible counts, not sampled expiration events.