Skip to main content
Fundamentals CDNCachingPerformanceStatic AssetsEdge

Content Delivery Networks (CDN)

A CDN caches content at globally distributed edge nodes, reducing latency for users worldwide and offloading traffic from your origin servers. Learn how CDNs work, when to use push vs pull, and how to design around CDN limitations.

9 min read

What Is a CDN?

A Content Delivery Network (CDN) is a geographically distributed network of proxy servers — called edge nodes or Points of Presence (PoPs) — that cache content close to end users. When a user requests content, the CDN routes the request to the nearest edge node. If the node has a cached copy, it serves it directly (cache hit). If not, the edge node fetches the content from your origin server, caches it, and serves it to the user (cache miss on the first request, cache hit for subsequent users in the same region).

The result: lower latency (the user fetches content from a server hundreds of kilometers away instead of thousands), higher throughput (CDN handles the traffic so your origin does not), and improved reliability (if your origin is slow, cached content is still available).

Common CDN providers: Cloudflare, AWS CloudFront, Fastly, Akamai, Google Cloud CDN.

What Gets Served From a CDN?

Static assets are the primary use case: HTML, CSS, JavaScript bundles, images, videos, fonts, and downloadable files. These change infrequently and are identical for all users, making them ideal for caching.

Dynamic content can also be accelerated by CDNs through smart routing (the CDN uses its optimized backbone network to forward requests to your origin faster than the public internet), TCP connection reuse (the CDN keeps warm connections to your origin), and edge compute (Cloudflare Workers, AWS Lambda@Edge) — small functions that run at the edge to personalize responses without hitting your origin.

What should not go through a CDN: highly personalized responses that cannot be shared across users (e.g., a shopping cart page), API endpoints that must read fresh data on every request, or real-time data streams.

Push CDN vs Pull CDN

Push CDN: you proactively upload content to CDN edge nodes before any user requests it. You are responsible for pushing new content whenever it changes and managing expiry. The CDN serves exactly what you push; there is no origin fallback on cache miss.

Best for: large static assets that change infrequently (videos, game binaries, large files), when you need precise control over what is cached and when, and low-traffic sites where pull CDN warm-up latency is unacceptable.

Pull CDN: the CDN pulls content from your origin on the first cache miss in each edge region. You configure origin URL, cache rules, and TTLs. The CDN handles all the replication automatically.

Best for: web assets (CSS, JS, images) that are updated with deployments, high-traffic sites where each file will be requested by many users in each region (making cache warm-up time negligible), and teams that want zero infrastructure management overhead.

Most modern web applications use pull CDN for simplicity.

Cache Invalidation and TTLs

CDN caches content for the duration of the TTL (Time To Live) you configure via HTTP response headers: Cache-Control: max-age=86400 tells CDN edge nodes to cache the response for 86,400 seconds (24 hours).

When you deploy an updated file at the same URL, edge nodes continue to serve the old cached version until the TTL expires. The two solutions:

Cache busting: append a content hash or version to the filename (main.abc123.js). The URL changes on every deploy, so CDN treats it as a new object and fetches it immediately. Old files expire naturally. This is the recommended approach for JavaScript and CSS bundles.

Cache purge/invalidation: send an API call to the CDN to invalidate specific URLs or prefixes immediately. Cloudflare and CloudFront both support this. Use for urgent fixes where you cannot wait for TTL expiry (e.g., serving a bad .js file that crashes your site).

For HTML files that reference versioned assets, set a short TTL (60–300 seconds) or no-cache so users always get fresh HTML that references the latest asset URLs.

CDN Considerations in System Design

Cost: CDN pricing is based on bandwidth transferred (GB/month) and the number of requests. For video streaming or high-traffic sites, CDN costs can be significant. Model the cost before assuming a CDN is always the cheapest option — in some cases, serving from a single well-provisioned origin is cheaper at low scale.

Stale content: a cache hit returns stale data if the TTL has not expired. For content that must always be fresh (account balances, order statuses), either bypass the CDN entirely or use CDN edge compute to validate freshness before serving.

HTTPS/TLS: CDNs terminate TLS at the edge, so connections from users to the edge node are encrypted. The connection from edge to origin can be HTTP or HTTPS depending on your configuration. Always enforce HTTPS origin connections for security.

Global load distribution: a CDN with anycast routing means the DNS for your domain resolves to the nearest CDN PoP, inherently distributing traffic geographically without requiring multi-region deployments of your application.

View all →

Apply Your Knowledge

All case studies →

Syed Peera Saheb

LinkedIn · Substack

Buy me a coffee