Concept · Networking & APIs
Content delivery networks
Edge caches close to users: what they cache, how they invalidate, and what they protect.
3 minCDNedge cache
A content delivery network is a fleet of caching servers in hundreds of locations ("edges" or points of presence). Users connect to a nearby edge; the edge serves cached responses or fetches them from your servers (the origin) on a miss.
What a CDN buys you
- Latency: a user in São Paulo is served from São Paulo, not Virginia — tens of milliseconds instead of a couple of hundred, and TLS handshakes complete nearby.
- Origin offload: a 95% cache hit rate means your servers see one request in twenty.
- Protection: CDNs absorb traffic spikes and volumetric DDoS attacks, and often provide a web application firewall and bot management.
What to cache, and for how long
| Content | Caching |
|---|---|
Versioned static assets (app.3f9a2c.js) | Cache-Control: public, max-age=31536000, immutable — a new version gets a new URL |
| Images and video | Long TTLs; often resized or transcoded at the edge |
| Public HTML or API responses | Short TTLs (seconds to minutes), plus stale-while-revalidate |
| Personalised responses | Cache-Control: private or no-store — never shared at the edge |
The cache key is the URL plus whatever the Vary header names. Vary on as little as possible: varying on Cookie effectively disables caching.
Invalidation
- Versioned URLs are the most reliable: change the URL and the old object simply stops being requested.
- Purge APIs remove a path (or everything tagged with a surrogate key) from all edges, typically within seconds.
- Short TTLs bound staleness when purges are missed.
Pitfalls
- Caching responses that set cookies or contain personal data — a classic way to show one user another user's account page.
- Forgetting that a 404 or 500 may be cached too; set short TTLs for errors.
- Assuming a purge is instant everywhere; design for a few seconds of overlap.
See caching patterns and cache invalidation.