Content Consistency: Polling, TTL, and Leases
Why this matters: 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.
Key takeaway
Proxy servers must remain consistent with origin servers to prevent users from accessing stale data. Which mechanism you use depends partly on whether you are running a push or pull model.
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.
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.
Comparing the three
| Mechanism | Direction | Staleness window | Cost |
|---|---|---|---|
| Periodic polling (TTR) | Proxy asks on a schedule | Up to one TTR interval | Wasted bandwidth when content rarely changes |
| TTL | Proxy revalidates on expiry, when requested | Up to the TTL | A revalidation round trip per expiry, only for requested objects |
| Leases | Origin notifies the proxy | Near zero while the lease holds | Origin must track outstanding leases — real state |
Key takeaway
Polling wastes bandwidth on unchanged content. TTL bounds staleness cheaply and only for content anyone wants. Leases give near-immediate freshness by moving the bookkeeping to the origin. Most CDNs run TTL by default and reserve purge for the cases that cannot wait.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We set a TTL so the cache refreshes." |
| L5 | Compares options: "TTL rather than periodic polling, since polling wastes bandwidth revalidating content nobody requested." |
| Staff+ | Names the inversion and the gap: "leases push invalidations from origin so freshness is near-immediate, at the cost of origin tracking every outstanding lease — adaptive leasing bounds that. And TTL can't handle a takedown; that needs explicit purge." |
Next: where to physically put the proxies.