CDN Is Not Just for Frontend. Backend Developers Need to Understand It Too.

The Backend Engineer's Blind Spot

CDNs — Content Delivery Networks — get categorized as a frontend concern. Static assets, HTML, CSS, images: put them on Cloudflare or CloudFront, serve them from edge nodes close to the user, done. Backend developers ship the API and consider CDN someone else's problem.

This mental model misses a significant part of what CDNs can do. Modern CDN platforms like Cloudflare, Fastly, and AWS CloudFront are programmable proxies that sit between your users and your origin. They can cache API responses, transform requests, implement rate limiting, handle authentication, and terminate connections close to the user — all before the request reaches your application server.

Understanding CDN semantics is not optional for backend engineers who care about latency, reliability, and cost.

What CDNs Actually Cache

CDNs cache HTTP responses based on the response headers your server sends. The key headers:

Cache-Control: the primary directive. public, max-age=300 means cache this response at all layers (CDN, browser) for 300 seconds. private, max-age=0 means do not cache at shared layers (the CDN will not cache this). no-store means cache nothing anywhere.

Vary: tells the CDN to cache separate copies based on specific request headers. Vary: Accept-Encoding means cache a separate copy for gzip and non-gzip clients. Vary: Accept-Language means cache a separate copy per language. Overusing Vary fragments the cache and reduces hit rates.

Surrogate-Control / CDN-Cache-Control: Fastly and Cloudflare support extended headers that give CDNs different instructions than browsers. You can tell the CDN to cache for 24 hours while telling browsers to cache for 5 minutes — useful for controlling freshness at each layer independently.

# API response headers for cacheable public content:
Cache-Control: public, max-age=60, stale-while-revalidate=30
CDN-Cache-Control: max-age=300
# Browser caches for 60s, CDN caches for 300s
# stale-while-revalidate: CDN serves stale content for 30s while fetching fresh

API Responses That Benefit from CDN Caching

Not all API responses are cacheable. User-specific, authentication-required responses must not be cached at a shared CDN layer — you would be serving one user's data to another. The candidate responses are:

Public, non-personalized data. Product catalogs, blog post content, pricing pages, public user profiles, sports scores, weather data, currency rates. These can be cached aggressively.

Authenticated but non-personalized data. Reference data that is the same for all authenticated users — feature flag configurations, application configuration, taxonomy data. These can be cached at the CDN if the cache key excludes the authentication token but the CDN validates authentication independently.

Expensive-to-compute aggregated data. Leaderboards, trending content, search results for common queries. Computing these for every request is expensive. Computing them once and caching at the CDN for 60 seconds reduces origin load by the factor of your cache hit rate.

What CDNs Do Beyond Caching

TLS termination at the edge. The TLS handshake — the cryptographic negotiation that precedes every HTTPS connection — takes multiple round trips. A user in Tokyo connecting to an origin in Virginia makes those round trips across the Pacific. If the CDN terminates TLS at a Tokyo edge node, the handshake round trips are milliseconds, not hundreds of milliseconds. The remaining connection to your origin is over the CDN's private backbone — typically faster and more reliable than public internet.

DDoS mitigation. CDN edge nodes absorb volumetric attacks — traffic floods — before they reach your origin. A 10 Gbps flood to your origin is an outage. A 10 Gbps flood to Cloudflare's network is routine for them.

Edge compute. Cloudflare Workers, Fastly Compute@Edge, and Lambda@Edge allow you to run code at the CDN edge. Auth token validation, A/B test assignment, request routing, and response transformation can happen at the edge without a round trip to the origin. This is increasingly important for latency-sensitive applications.

What Backend Engineers Should Configure

Set explicit Cache-Control headers on every API response. Do not rely on CDN defaults — they vary by provider and often default to no-cache for API responses. If a response is public and cacheable, say so. If it is private, say so. If it must not be cached under any circumstances, say no-store.

Use surrogate keys (Fastly) or cache tags (Cloudflare) for targeted invalidation. Tag cache entries with identifiers (product ID, category ID) so you can invalidate all cached responses for a specific product without purging the entire cache. This is how you get aggressive CDN caching with on-demand invalidation.

CDN configuration is backend configuration. Own it.