A cached response is fresh for a specified period, then stale. Revalidation asks the origin whether it changed; an ETag can allow an unchanged representation to return a compact response. Stale-while-revalidate permits a cache to return an older copy during a bounded window while it updates in the background. That can be valuable for public content, yet it is wrong for a permission or case-status decision that must be current before action. A purge removes particular cached objects, but invalidation across many edge locations may not be instantaneous. Versioned URLs avoid some purge races for immutable assets; mutable HTML needs a clear freshness or revalidation contract.
Make this comfortable
Stale Revalidation and Versioned Purges
Working case
A public inspection guide changes its safety checklist at noon. The site allows a brief stale window so readers get the page quickly while edges refresh it. The editorial system also issues a purge for the guide URL and its locale variants. A reviewer dashboard follows a different rule: a stale queue count may be visible with a timestamp, but a Resolve action always asks the server for current permission and version. The team must decide whether the guide's old checklist is acceptable for the stale window; if not, that page should revalidate rather than serve stale.
Implementation boundary
function mayServeStale(contentKind, staleSeconds, allowedSeconds) {
return contentKind === "public-guide" && staleSeconds >= 0 && staleSeconds <= allowedSeconds;
}
console.log(mayServeStale("private-case-status", 12, 30));
// Output: falseDocument freshness by content class: fingerprinted assets, public pages, search indexes, and private operational records have different consequences. An ETag should identify a representation and remain consistent with its content encoding and language variant. A purge event should carry the URLs or tags it affects, and a verification job should sample edges after publication. Where a release changes code and HTML together, use versioned assets so old HTML can still load compatible code during rollout. Never rely on a client-visible stale record to authorize a write; the server checks the current version at mutation time.
Cost and boundaries
Longer freshness windows reduce origin reads but increase maximum age of an incorrect copy. A purge fan-out across e edge locations costs at least O(e) invalidation work and may complete at different times. Revalidation adds a request even when the body is unchanged, while a stale response can hide that latency at the cost of temporary inconsistency. Versioned assets increase retained storage across releases but simplify cache reasoning. Measure age distribution, purge completion, origin load, and user-visible correction time, not only cache hit ratio.
Failure trace
An editor corrects a dangerous line in a guide, but the purge only targets the default-language URL. Another locale continues to serve the old text under stale-while-revalidate. Link all variants to the publication event and check each one after purge. A different failure occurs when a deployment changes an unversioned script while old HTML remains cached; the new script expects markup the old page does not contain. Use content-hashed assets and a compatibility window between HTML and code. Keep sensitive operational content on a stricter policy.
Verification
- All published guide variants reach the intended revision after purge.
- Old HTML can load compatible versioned assets during rollout.
- A stale case view cannot authorize an obsolete write.
Practice drill
Publish guide revision 47 and request it from two simulated edge regions and two locales before and after purge. Record Age, ETag, and body revision; decide whether any stale observation breaches the guide's contract. Delay one edge purge and verify the site reports it rather than claiming global completion. Next deploy changed HTML and JavaScript in opposite orders, using versioned asset URLs to test compatibility. Attempt a case mutation from a stale detail view; the conditional server write must reject an obsolete version.
Decision note
Permit stale reuse only when the content's consequences allow it, and verify invalidation across every representation.
Common Mistakes
- Assuming purge is instant everywhere.
- Applying one stale window to public guidance and private actions.
- Forgetting locale or encoding variants during invalidation.
Connected lessons
HTTP Delivery and Cache Ownership; Shared Cache Keys and Private Response Boundaries; Content Negotiation and Compression Contracts; Critical Resource Discovery and Priority; HTTP caching: validate a changed representation with an ETag; Continuous Integration and Release Gates; Conditional Writes and Lost-Update Prevention.
Apply and check
Build Project: edge cache and critical resource release and review Web Development: navigation and delivery decisions quiz.
Further connections
web-tech
web-development