A publishing system may cache HTML, API JSON, redirects, and assets at different layers. Each layer needs an explicit key, lifetime, and invalidation path. An update to a CMS record does not automatically invalidate every rendered URL that mentions it. A changed lesson may affect its canonical page, a topic index, a search feed, and related-lesson cards. Purge only the affected keys when the provider supports it, and use a bounded time-to-live as a recovery path when purge delivery fails. A redirect can introduce another cached location, so test both the requested path and its destination. Keep private or preview responses out of shared caches.
Make this comfortable
Published content caches: bound the stale window and purge the right key
Operational decision
A published guide changes from revision 72 to 73. The origin shows 73, but a reader still sees 72 on the guide path and an index card. The operator inventories both affected URLs, checks cache headers and the actual edge key, and issues an invalidation for those keys. It then probes through the public hostname until both paths return 73 or the documented 900-second maximum age expires. A failed purge does not make stale content permanent because the TTL is bounded. If revision 73 contains a legal correction requiring immediate removal, the operator uses the emergency bypass or temporary route block while invalidation is verified from more than one location.
Content revision: 73
Affected keys: guide route, topic index, search feed
Public maximum age: 900 seconds
Purge receipt: request identity and result
Verification: route and index show revision 73
Fallback: expiry or emergency bypassCost and verification
If U rendered URLs depend on one record, precise invalidation is O(U) key operations; broad purges cost fewer commands but increase origin traffic and can create a stampede. Keep a dependency map for high-impact surfaces and measure origin load after purge. A 900-second TTL sets an upper stale bound only when every cache honors it and the origin serves the new version. Monitor CMS-to-edge lag at p95 and the oldest stale route, not just purge API success.
Common Mistakes
- Do not purge an origin URL while readers use a different edge key.
- Do not cache preview or private responses in a shared layer.
- Do not assume that purging one lesson updates every index that embeds it.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Headless CMS publishing: define which records become public routes
- Versioned edge assets: make long cache lifetimes safe through content identity
- Edge cache fallback: serve stale public data without leaking private responses
Practice and check
devops
web-publishing