Content Consistency: Polling, TTL, and Leases

In one line: every cached copy is a chance to serve something wrong. These three mechanisms are the spectrum from "ask constantly" to "be told" — and they trade bandwidth against staleness in different places.

Periodic polling

In the pull model, proxy servers periodically fetch updated content from the origin. The model defines a time-to-refresh (TTR) interval specifying how frequently proxies revalidate or fetch updates.

The problem is visible in the diagram: periodic polling can waste bandwidth when content changes infrequently. Most of those round trips return "nothing changed" — you pay for the question regardless of the answer.

Time-to-live (TTL)

To reduce unnecessary refresh requests from fixed TTR intervals, TTL assigns an expiration time to each object.

Proxies serve the cached object until the TTL expires. After expiration the proxy revalidates with the origin: if the object has changed it retrieves the updated version, otherwise it continues serving the cached copy and resets the TTL.

Why TTL beats fixed polling

Polling is time-driven — it revalidates on a schedule whether or not anyone wants the object. TTL is request-driven — an expired object is only revalidated when someone actually asks for it.

For a CDN holding a long tail of rarely-requested content, that difference is enormous. Polling would revalidate millions of objects nobody is reading; TTL costs nothing for an object with no traffic.

This is also DNS's TTL, doing the same job at a different layer: bounding staleness without requiring the design to track who holds a copy.

Leases

The origin server grants a lease to the proxy. The lease defines a time interval during which the origin agrees to notify the proxy of any data changes. Once the lease expires, the proxy requests a renewal.

This reduces message volume between proxy and origin: instead of the proxy repeatedly asking, the origin promises to tell it. Lease duration can be dynamically optimized based on proxy load — a technique known as adaptive leasing.

Leases invert who does the work

Polling and TTL are proxy-driven: the proxy asks, the origin answers. Leases are origin-driven: the origin remembers who holds what and pushes invalidations.

That inversion buys freshness — a change propagates immediately rather than at the next expiry — and costs the origin state. It must track every outstanding lease, which is exactly the coordination burden CDNs otherwise avoid. Adaptive leasing exists to bound that: shorten leases when the origin is tracking too many, lengthen them when it can afford to.

Comparing the three

TTL is a promise about staleness, not freshness

Setting a TTL of 60 seconds does not mean content updates within 60 seconds. It means a proxy may serve content up to 60 seconds old before it next checks — and if nobody requests the object, it simply sits there expired.

For content that must change immediately — a legal takedown, a mispriced product, a leaked asset — TTL is the wrong tool entirely. That is what explicit purge is for, and it is why the previous lesson noted that deletion is sometimes required despite eviction policies.

Content that is not public

Everything so far assumes anyone may fetch the object. Much of what a CDN serves is not like that — a paid video, a private document, a user's own upload — and the obvious approaches both fail.

Checking permission at the edge means the edge must reach your service to ask, which reintroduces the origin round trip the CDN existed to remove. Not caching private content at all gives up the CDN for exactly the large files that need it most.

The workable answer is a signed URL: your service, which already knows who the user is and what they may see, issues a link carrying an expiry and a signature computed with a key the CDN also holds. The edge verifies that signature by itself — arithmetic, not a network call — and serves or refuses.

Three properties make it fit:

Authorization happens once, at your origin, when the link is minted. The edge is only checking that a decision was made, not making one.

The object stays cacheable. The signature travels in the query string or a cookie and is deliberately excluded from the cache key, so a thousand users with a thousand different signatures still share one cached copy — which connects directly to the key discussion earlier: this is a case where a parameter must be removed from the key for the design to work at all.

Expiry is enforced at the edge, so a leaked link stops working on its own. That is what makes short-lived links safe to hand out.

The limits are worth stating rather than glossing. A signed URL is a bearer token: anyone holding it has access until it expires, so the expiry is doing the security work and it should be short. Revoking a specific link before expiry is not naturally possible, since the edge is verifying a signature rather than consulting a list. And if the response itself differs per user, this does not help — you are back to content that must not be shared, which belongs outside the cache entirely.

Interview signal by level

Next: where to physically put the proxies.