Skip to content
AITroveRead. Build. Understand.
Reading list
Make this comfortable

Edge Cache Locality, Invalidation, and Private Scope

Last updated: 5 Oct 20268 min read
tutorial
IntermediateBy AITrove Editorial

A cache at one edge location is a copy, not the origin record. Some edge cache APIs operate per data center, while a platform-level cache or tiered fetch may have different propagation and purge behavior. A successful delete in one location must not be assumed to erase every other copy. Cache identity must include every request dimension that changes the representation; adding all cookies by default can destroy hit rate or place session material in cache metadata. Public immutable assets are easier to cache than private case data. For private responses, explicit bypass or tightly scoped authorization is usually safer than broad shared caching.

Working case

The permit portal updates a public district map style from revision 29 to 30. A purge executed near one office removes its local tile, but another region still serves the old revision. The fix gives public assets revisioned URLs so old and new tiles can coexist until clients move. A separate private case thumbnail must never share a cache entry across reviewers or tenants. It is fetched through an authorized route with private response policy, not placed behind a public tile key. When reviewer 47 loses access, a local cache hit cannot continue showing case 62’s thumbnail.

Implementation boundary

javascript
function publicTileKey(styleRevision, language, tileId) {
  return `style:${styleRevision}:lang:${language}:tile:${tileId}`;
}
console.log(publicTileKey(29, "en", "12-47-63") === publicTileKey(30, "en", "12-47-63"));
// Output: false

Classify each response as immutable public, mutable public, user-scoped private, or never-cache. For immutable assets, include a content or release revision in the URL and set a suitable lifetime. For mutable public data, define freshness, revalidation, and purge scope across edge locations; test the actual platform behavior. For private records, apply current authorization before any cache lookup that can expose data, or bypass shared caches. Build cache keys from normalized URL and only the headers, query fields, or identity dimensions that actually change the representation. Treat an authorization header or cookie as a sensitive input, not a reason to copy the whole value into arbitrary cache keys. Record which layer holds copies: browser, service worker, edge, regional shield, and origin.

Cost and boundaries

A revisioned asset rollout uses storage for two versions until old clients expire, but avoids an unreliable global purge race. Adding V variant dimensions can multiply cache entries and reduce hit rate; omitting one can return the wrong body. Revalidation adds an origin round trip, while longer freshness reduces origin load at the price of delayed updates. A per-location cache may produce different hit ratios and stale windows by region. Measure hit rate, origin fetches, oldest served revision, bytes stored per variant, and private-response cache bypass. Purging every key on every write can cost more than using versioned object identity.

Failure trace

Warm two edge locations with style revision 29, purge only one, then request both; the system must not claim global invalidation from a local delete. Deploy revision 30 with a new URL and verify both regions can serve the correct one. Vary a district language or representation selector while keeping the same path and check cache identity. Send reviewer 47 and reviewer 62 through a shared private thumbnail URL and prove neither receives the other’s bytes. Remove access after a cached response exists; a current unauthorized request must still fail.

Verification

  • Public asset revisions have separate identities across locations.
  • Private case responses cannot be served through shared public cache keys.
  • Purge tests cover every cache layer used in production.

Practice drill

Publish 63 public map tiles under revision 29, then release revision 30 without overwriting the old URLs. Simulate two edge locations and a regional shield; record which layer holds each revision. Build cache keys for language and style revision, but do not vary on unrelated request noise. Add a private case image route and try two tenants, a role change, and a browser back request. Report stale-public behavior separately from private-access failure; they have different acceptable outcomes.

Decision note

Use versioned public assets and explicit private scope; cache invalidation must match the actual locations that hold copies.

Common Mistakes

  • Assuming one local cache delete invalidates every region.
  • Adding every cookie to a cache key without a representation reason.
  • Caching private bytes before checking current access.

Related lessons

Edge Runtime and Origin Boundaries; Edge Request Normalization and Origin Trust; Edge Compute Budgets and Upstream Fanout; Edge-to-Origin Write Routing and Consistency; Shared Cache Keys and Private Response Boundaries; Stale Revalidation and Versioned Purges.

Apply and check

Build Project: edge permit case delivery and review Web Development: edge and origin contracts quiz.

web-tech
web-development
Storage details