This simulator follows one cacheable object across a small edge network. A viewer requests it repeatedly through an edge region; the edge either serves it from cache or fetches it from the origin. You set the time-to-live and trigger an origin update or outage to see freshness and availability trade off.
• A 3D geographic map with a viewer device, Western, Central and Eastern edge caches and an origin content server. • Controls for cache TTL (1 to 12 seconds), viewer request interval (0.5 to 3 seconds), the viewer's edge region, whether the origin publishes version 2 at 6 seconds, and whether the origin becomes unavailable after 8 seconds. • Readouts for viewer requests, cache hits, cache misses, origin failures, last successful content version and mean request latency. • Experiments for cache reuse, observing an older valid version, and an origin outage after expiry.
A request is a hit when the object exists in that edge cache and the request time is before its expiry; otherwise it is a miss and the edge fetches from the origin, and a successful fetch sets expiry to the request time plus TTL. With the illustrative latencies of 20 ms for a hit, 140 ms for a miss and 200 ms for a failed origin, a longer TTL raises the hit share and lowers mean latency. The trade-off is freshness: after the origin publishes version 2, an unexpired edge keeps serving version 1 until its TTL runs out. If the origin then goes offline, an expired edge misses and reports an error.
The model has a single cache key, three independent edge caches and immediate fetch completion at request events. It excludes validation headers, request coalescing, eviction, invalidation and stale-on-error, so an expired object is not served during an outage. Latency figures are illustrative, not measurements of any provider.
No. TTL and invalidation policy govern when edges refresh. In the lab, an edge holding an unexpired version 1 keeps serving it after the origin publishes version 2.
The edge must hold the object and the request time must be earlier than its expiry. After a miss, a successful origin fetch stores the object with expiry equal to the request time plus the TTL.
No. Stale-on-error is explicitly excluded, so an expired object is not served during an outage; the request misses and is counted as an origin failure.
A longer TTL keeps the object valid longer, so more requests are hits at the illustrative 20 ms instead of misses at 140 ms. The cost is that viewers may see an older version for longer after the origin changes.