All Posts

Cache invalidation is how you ensure users don’t keep receiving stale content after you deploy an update. Without invalidation, a CDN might continue serving an older cached copy until its TTL expires. There are a few common strategies: short TTLs (simple but less efficient), versioned URLs (best for static assets), and explicit purges (invalidate specific paths or patterns when you publish changes). The goal is to balance freshness and performance: invalidate only what change

Cookies often signal that a response is personalized—think logged-in state, location, or A/B test buckets. If a CDN cached one user’s personalized page and served it to others, it would be a privacy and correctness problem. To avoid that, many CDNs treat requests with certain cookies as uncacheable, or they vary the cache key by cookie values. Both approaches reduce cache hit rates because the content becomes fragmented into many versions. A common fix is to keep truly person

CDNs run thousands of edge servers in data centers across continents so content can be delivered from a location close to each visitor. The closer the edge is to the user, the fewer network hops and the lower the round‑trip time. When a request arrives, the CDN routes it to an optimal edge based on latency, capacity, and network conditions. This routing can change dynamically as traffic shifts or outages occur. Because edges are distributed, they also add resilience: if one r

A cache hit happens when a user requests a file (like an image, CSS, or HTML) and the CDN already has a fresh copy stored at the edge. The edge server can return it immediately without contacting your origin, which reduces latency and lowers load on your infrastructure. A cache miss occurs when the edge server doesn’t have the content yet, or the cached copy has expired or been invalidated. In that case, the CDN fetches the asset from the origin (or an upstream cache), serves