Regional Routing, Static and Private Cache Boundaries

Working case

Reviewers in regions 29 and 47 load the same hashed interface bundle from nearby caches. Their case requests carry authentication and tenant context to a permitted backend. The public bundle is shared; case 62 detail is never placed in a shared cache keyed only by URL. Reviewer 29 switches organizations, and a prior private response is no longer eligible for reuse. During a regional traffic shift, the browser fetches a fresh authorized case response from the selected backend rather than accepting a different tenant’s warm edge entry.

Implementation boundary

function sharedCacheAllowed(kind, authenticated) {
  return kind === "immutable-public" && !authenticated;
}
console.log(sharedCacheAllowed("case-detail", true));
// Output: false

Classify responses as public immutable assets, public revalidated content, and private user or tenant data. Make cache directives and keys match that classification. If any private response is cached, include all effective permission scope in its key and ensure invalidation can reach every serving layer; in many systems, no shared caching is simpler. Route writes to the authority for the record. Keep session verification and tenant checks at the backend even when an edge validates a token. Document which hop handles TLS, cache, logs, and origin fetch when a location restriction applies.

Cost and boundaries

Global public caching saves origin requests and asset latency, while private misses still pay the distance to the authoritative service. Routing to a close application instance that calls a far database can add an extra network hop instead of helping. More regions multiply cache purge, configuration, and observability surfaces. Measure full request latency by path, origin egress, cache hit rate by response class, and permission-denied responses. Do not infer residency from the browser’s nearest point of presence; trace each storage and processing hop.

Failure trace

A case detail response is cached by pathname, then reviewer 47 receives reviewer 29’s case after traffic moves to another edge. Remove the shared cache route, purge affected entries, and test tenant changes. Another design routes writes to the nearest app while both apps point at different primaries, producing divergent cases. Test cross-tenant URL collision, logout, account switch, stale edge configuration, unhealthy region, a cache purge delay, and an origin that is farther than the original direct route.

Verification

• Private case responses cannot cross tenant context.
• Writes have one named authority.
• Every processing and storage hop has a location decision.

Practice drill

Write a response inventory for scripts, help pages, case lists, and case detail. Assign cache and routing rules to each. Create two reviewer sessions for case 62 with different rights, warm an edge with the first, then request with the second. Shift traffic between regions and inspect which origin handles a write. Record each location where private bytes and request logs can exist; verify the stated data-location policy against that inventory.

Decision note

Cache public artifacts broadly and route private state by authority and permission, not by nearest geography alone.

Common Mistakes

• Using URL alone as a private cache key.
• Confusing edge proximity with database proximity.
• Assuming a nearby edge defines data residency.

Connected lessons

Build Project: two-region case service recovery and review Web Development: motion and regional state decisions quiz; follow Multi-Region Web State and Recovery; Replica Lag, Read-Your-Write, and Version Cursors; Regional Failover, Fencing, and Replay; Regional Data Location and Operational Evidence; Shared Cache Keys and Private Response Boundaries; Horizontal Scale and Shared State.

Further connections

Artifact Manifest, Rollout, and Rollback Coherence.