Guide

CDN explained

A visitor in Tokyo requests your product image hosted in Virginia. Without a CDN, the file crosses the Pacific on every page load — 150–250 ms of latency before bytes even arrive. A content delivery network (CDN) stores copies at edge points of presence (PoPs) worldwide so most requests terminate a few milliseconds from the user. CDNs also absorb traffic spikes, terminate TLS closer to clients, and filter DDoS attacks before they reach your origin. This guide covers how edge caching relates to HTTP caching headers, DNS and anycast routing, cache hierarchies and origin shields, purge and invalidation strategies, what belongs on a CDN versus your reverse proxy or load balancer, security features (WAF, bot management), provider trade-offs, a global e-commerce worked example, a decision table, common pitfalls, and a production checklist.

What a CDN does

A CDN is a distributed network of cache servers that sit between users and your origin — the server or storage bucket where content lives. On a cache miss, the edge PoP fetches from origin, stores the response, and serves subsequent requests locally. On a hit, the edge returns cached bytes without touching origin at all.

The primary wins are latency reduction (shorter network paths), origin offload (fewer requests and less egress bandwidth on your servers), and resilience (the CDN absorbs flash traffic and volumetric attacks). Modern CDNs also run compute at the edge (Workers, Lambda@Edge, Cloudflare Workers) for lightweight transformations, A/B routing, and auth checks — blurring the line between CDN and API gateway.

CDNs are not a replacement for application-level caching in Redis or database query optimization — they accelerate delivery of bytes already computed, not the computation itself.

Edge caching and cache hierarchies

Each PoP maintains an in-memory and disk cache governed by the same Cache-Control, ETag, and Expires headers described in HTTP caching. You configure CDN-specific behaviors: default TTLs, query-string handling (ignore vs vary), cookie bypass rules, and stale-while-revalidate at the edge.

Large CDNs use tiered caching: a regional mid-tier or origin shield consolidates misses from many edge PoPs into a single origin fetch. Without a shield, a viral asset can trigger thousands of simultaneous origin requests — the thundering herd problem. Origin shields also let you keep a smaller, fixed set of origin IP allowlists.

Cache key design matters: two URLs that return identical bytes but differ in query order or trailing slashes may cache separately, wasting space. Normalize URLs at the edge and use content hashing in filenames (app.a3f9c2.js) so you can set Cache-Control: immutable, max-age=31536000 safely.

DNS, anycast, and routing users to the nearest PoP

Most CDNs route traffic via DNS: your www.example.com CNAME points to the provider, which returns different edge IP addresses based on the resolver's geographic location (GeoDNS). Some providers use anycast — the same IP announced from many PoPs, with BGP routing delivering packets to the topologically nearest node.

DNS TTL affects failover speed: a 300-second TTL means up to five minutes before users see a routing change. For critical cutovers, lower TTLs in advance. Certificate management is usually handled by the CDN (automated ACME/Let's Encrypt at the edge), simplifying TLS for multi-region deployments.

Orange-cloud / proxied mode (terminology varies) means traffic flows through the CDN's network; DNS-only mode resolves to your origin IP without caching or WAF — useful during migration or debugging.

What to put on a CDN

Content type	CDN fit	Notes
Fingerprinted static assets (JS, CSS, fonts, images)	Excellent	Long TTL, immutable flag; origin rarely contacted
HTML pages	Conditional	Short TTL or stale-while-revalidate; watch personalized cookies
Public API GET responses	Conditional	Only if cacheable and auth-safe; use `Vary` carefully
Authenticated / session-specific data	Poor	Bypass cache or use private, no-store headers
WebSocket / SSE streams	Poor	CDN proxies connection but does not cache; check provider support
Large file downloads / video	Excellent	Range requests, adaptive bitrate; major cost savings on egress

Dynamic site acceleration features (connection reuse, TCP optimization, route selection) speed uncacheable HTML without storing responses — useful for logged-in dashboards where full page caching is impossible.

Purge, invalidation, and deployment workflows

When you deploy a non-fingerprinted asset, stale edge copies must be removed. Options:

URL purge — invalidate specific paths; propagates in seconds to minutes depending on provider.
Wildcard / tag purge — invalidate by cache tag or prefix (e.g. all /assets/*).
Surrogate-Key headers — origin tags responses; purge by key without listing every URL.
Versioned deploys — prefer fingerprinted filenames so purges are unnecessary; old and new assets coexist during rollout.

Integrate purges into CI/CD after uploads complete. A purge-before-upload race leaves users with 404s at the edge. For blue-green deployments, warm the CDN on the new origin before switching DNS.

Security: DDoS, WAF, and bot protection

Because all traffic passes through the CDN, it becomes your first line of defense. Volumetric DDoS attacks are absorbed across the provider's network capacity — often terabits — rather than your single origin. Web Application Firewalls (WAF) inspect HTTP for SQL injection, XSS, and OWASP Top 10 patterns. Bot management distinguishes search crawlers from credential-stuffing bots via JavaScript challenges, behavioral signals, and rate limits.

Trade-off: aggressive bot filtering can block legitimate API clients or accessibility tools. Maintain bypass rules for monitoring probes and partner integrations. Log sampled edge requests to your observability stack for incident forensics.

Provider landscape and cost model

Major providers include Cloudflare (generous free tier, integrated DNS), Amazon CloudFront (tight AWS integration), Fastly (instant purge, edge compute), Akamai (enterprise scale), Google Cloud CDN, and Azure Front Door. Selection factors: PoP density in your user regions, egress pricing from your origin cloud, purge latency, WAF rule flexibility, and contractual commit vs pay-as-you-go.

Cost drivers: egress bandwidth (per-GB), HTTP/HTTPS request count, WAF/bot add-ons, and log ingestion. Serving 10 TB/month from origin directly can cost 5–10x more than CDN egress in the same region. Monitor cache hit ratio — below 85% on static-heavy sites usually means misconfigured TTLs or cache key bugs.

Worked example: global e-commerce storefront

An online retailer hosts origin in us-east-1. Product images total 2 MB per page; 500,000 daily visitors split 40% Americas, 30% Europe, 30% Asia-Pacific.

Without CDN: APAC users see 180 ms RTT to origin; images load sequentially at ~4–6 seconds on 4G. Origin serves 500k × 2 MB = 1 TB daily egress.

With CDN: Images cached at Singapore, Frankfurt, and São Paulo PoPs. First visitor per region triggers one origin fetch per asset; subsequent visitors hit edge (<20 ms). Cache hit ratio on images reaches 97%. Origin egress drops to ~30 GB/day. Page image load time in Tokyo falls from 5 s to under 1 s. During a flash sale, edge serves 50× normal traffic; origin request rate rises only 3% due to shielding.

Configuration: fingerprinted assets with one-year TTL; HTML with max-age=60, stale-while-revalidate=300; cart/checkout paths bypass cache entirely; WAF blocks known bad ASNs; CI purges surrogate-key product-images on catalog updates.

CDN vs other layers — decision table

Need	Best layer	Why
Serve static files globally with low latency	CDN	Geographic distribution is the core value proposition
Cache database query results	Application cache (Redis)	CDN cannot see inside your app logic
Route internal microservice traffic	Service mesh / load balancer	CDN is for north-south (client-to-server) traffic
TLS termination at single data center	Reverse proxy (nginx)	Sufficient if all users are regional
Absorb traffic spikes on dynamic pages	CDN + autoscaling origin	CDN handles bytes; origin still scales for compute
Rate-limit API abuse per user	API gateway or edge worker	Needs identity-aware logic beyond byte caching

Common pitfalls

Caching authenticated responses — a Set-Cookie response cached at edge leaks one user's session to others. Default to bypass when cookies are present.
Ignoring Vary — serving gzip to a client that requested brotli corrupts payloads. Normalize or separate cache keys.
Purge storms during deploy — mass invalidation forces every PoP to refetch origin simultaneously. Prefer fingerprinted assets.
Stale HTML after CMS publish — editors see new content on origin but users see old cached pages. Use short TTLs or on-publish webhooks to purge.
Origin IP exposure — attackers bypass CDN and DDoS origin directly. Firewall origin to CDN IP ranges only.
Assuming CDN replaces monitoring — track hit ratio, origin offload, 5xx at edge vs origin, and TTFB by region.

Production checklist

Point DNS CNAME to CDN; enable proxied mode for public traffic.
Restrict origin firewall to CDN provider IP ranges.
Fingerprint static assets; set long immutable TTLs.
Configure cache bypass for auth, cart, checkout, and admin paths.
Enable origin shield or tiered cache for high-traffic assets.
Integrate surrogate-key or tag purges into deploy pipeline.
Enable TLS 1.2+ at edge; automate certificate renewal.
Turn on WAF with tuned false-positive monitoring.
Dashboard cache hit ratio, egress savings, and regional TTFB.
Document rollback: DNS-only fallback to origin if CDN fails.

Key takeaways

A CDN caches content at edge PoPs worldwide — reducing latency, origin load, and attack surface.
Edge behavior follows HTTP cache headers; fingerprinted assets and origin shields maximize hit ratio.
Purge strategy must match your deploy model — prefer versioned filenames over mass invalidation.
CDNs excel at static and cacheable content; pair with application caches and autoscaling for dynamic workloads.
Lock down origin IP, monitor hit ratio, and test failover before you need it.