CDN Cache Invalidation Strategies: Balancing Speed and Correctness

Using a CDN is easy; invalidating cache correctly is hard. A poor invalidation model either serves stale content too long or destroys cache hit ratio by purging too aggressively. Production success comes from policy by content type, not one global TTL.

Split content into classes

1. Versioned static assets (app.4f2a1.js)
2. Semi-dynamic HTML pages
3. Highly dynamic correctness-critical data

Client -> CDN Edge -> (hit?) -> response
                    -> (miss) -> origin -> cache according to headers

Policy that works

• Versioned assets: max-age=31536000, immutable
• HTML: short TTL plus stale-while-revalidate
• CMS updates: targeted purge by path/tag

Avoid full-cache purge after every deploy. It causes traffic spikes on origin, slower responses, and unnecessary cost.

Targeted purge example

Updated page: /blog/a
Purge:
 - /blog/a
 - /blog
 - related category pages
Do not purge unrelated URLs

This keeps correctness high while preserving edge hit ratio.

Metrics to monitor

• CDN hit ratio
• origin request volume
• p95 TTFB
• purge propagation time
• error rate trend after release

Without these metrics, invalidation quality is mostly guesswork.

Conclusion

Cache invalidation is a release engineering problem as much as a performance topic. With versioned assets, SWR for HTML, and targeted purge automation in CI/CD, teams can keep pages fast and content accurate at the same time.