Edge Caching / CDN
Term 17 of 68 in the ERPStack technical glossary
What is Edge Caching / CDN?
Edge Caching is the practice of storing static files, API JSON payloads, and pre-rendered HTML pages on servers located close to the user (at the 'edge' of the network) to reduce latency and speed up page load times.
Edge Caching / CDN at a glance
- Mechanism
- Responses served from a location near the user instead of 1 origin thousands of kilometres away
- Control
- Cache-Control and stale-while-revalidate headers, defined in RFC 9111 for HTTP caching
- Invalidation
- Tag-based purging so publishing 1 record clears 2 routes rather than the whole site
- Never cache
- Authenticated or tenant-scoped responses without a key that includes the tenant identity
- Built with
- Vercel edge caching in front of Next.js 16 and React 19, cache tags invalidated when Payload CMS content in PostgreSQL 18 changes, Redis at the origin, Sentry watching hit rates
- Numbers that matter
- RFC 9111 defines HTTP caching; publishing 1 record clears 2 routes; 0 shared caching of tenant-scoped responses; seconds of staleness, not hours
- Compare with
- Origin-only serving, Redis caching inside 1 region, or a CDN with 0 tag-based invalidation
- Commonly paired with
- Next.js 16 and React 19 rendering, a Headless CMS with Payload CMS content in PostgreSQL 18, Redis at the origin, Vercel or AWS hosting, Terraform configuration, Tailwind CSS 4 assets and Sentry monitoring
- Safety rule
- 0 shared caching of authenticated responses; tenant identity in the cache key or Cache-Control set to private, with 2 layers never sharing 1 key
- What is cached where
- Next.js 16 and React 19 output on Vercel or AWS, Payload CMS content from PostgreSQL 18 behind a Headless CMS, Tailwind CSS 4 assets at the edge and Redis at the origin.
- Who notices
- retail, media and hospitality traffic, where a 3-second first load and a 300-millisecond one are different conversion rates on the same page.
How Edge Caching / CDN works in production
The ERPStack approach to Edge Caching / CDN
We configure global edge caching on Vercel's Edge Network for all ERPStack marketing hubs and static assets, achieving sub-second load times.
Frequently asked questions about Edge Caching / CDN
What does Edge Caching actually remove?
Distance and repeated work. Edge Caching serves a response from a node near the user, so the request never crosses an ocean to reach the origin, and the origin never recomputes something it already produced. The gain is largest for content that is identical for many users, which is why marketing pages, documentation and catalogue data benefit far more than a personalised dashboard.
What is the hardest part of caching?
Invalidation, as the old joke has it. Edge Caching is easy to enable and hard to expire correctly: too aggressive and users see stale prices, too timid and the cache does nothing. Tag-based purging solves most of it by letting a content change invalidate exactly the routes that depend on it, which is far more precise than time-based expiry chosen by guesswork.
How do you cache safely in a multi-tenant system?
By making tenancy part of the cache key, or not caching at all. The catastrophic failure mode of Edge Caching in business software is 1 tenant's response being served to another because the key ignored identity. Anything authenticated should be private by default, and shared caching reserved for genuinely public content where the response does not vary by who asked.
What does stale-while-revalidate give you?
Speed without staleness compounding. The directive lets Edge Caching serve a slightly outdated response immediately while fetching a fresh one in the background, so the user waits for nothing and the next visitor gets current data. It suits content that changes occasionally and tolerates seconds of lag — which describes most catalogue, listing and documentation pages accurately.