Static Content Hosting Pattern
Serve static assets directly from object storage and CDNs: reducing server load, cache headers, versioned deployments, and edge computing.
What Is Static Content Hosting?
The Static Content Hosting pattern moves static assets — HTML, CSS, JavaScript bundles, images, fonts, and video — off your application servers and onto purpose-built infrastructure: object storage (S3, GCS) combined with a CDN (CloudFront, Cloudflare, Fastly). Application servers are freed from serving bytes and can focus entirely on computation. This is one of the highest-leverage performance optimizations available to any web system.
Netflix serves its frontend assets from S3 + CloudFront, reducing origin traffic by over 95%. GitHub Pages, Vercel, and Netlify are built entirely on this pattern — your repository's static output is deployed to edge nodes worldwide.
Architecture
Cache-Control Headers
CDN caching behavior is controlled by HTTP `Cache-Control` headers set on each asset. The optimal strategy is content-hash-based versioning: bundle filenames include a hash of their content (e.g., `main.a3f7b2.js`). Because the hash changes only when content changes, these files can be cached forever (`max-age=31536000, immutable`). HTML files, which reference the hashed assets, are cached for a very short time (`max-age=60`) or not at all.
| Asset Type | Cache-Control Header | Why |
|---|---|---|
| Hashed JS/CSS bundles | max-age=31536000, immutable | Content never changes for a given hash; cache forever |
| HTML files | max-age=60 or no-cache | HTML references hashed assets; must stay fresh so new deploys propagate |
| Images with hash in name | max-age=31536000, immutable | Same as JS/CSS — hash guarantees content integrity |
| API responses | no-cache or private | Dynamic content; should not be cached at CDN edge |
CDN Cache Invalidation
When assets are not hash-versioned, CDN cache invalidation becomes necessary on deploy. Most CDNs support path-based invalidation (`CloudFront: /static/*`). Invalidation propagates to all edge nodes but can take minutes. This is why hash-based versioning is preferred — no invalidation is needed because old URLs remain valid (pointing to the old build) and new URLs automatically get fresh files.
Atomic Deployments with Immutable URLs
Because hashed asset URLs are immutable, old and new versions of your application can coexist in the CDN simultaneously. During a deploy, users who loaded the old HTML continue using the old hashed assets (still cached at the edge). New users load the new HTML and get new hashed assets. There is no window where users get mismatched HTML and JS — this makes deployments atomic from the user's perspective.
Edge Computing Extension
Modern CDNs extend beyond pure file serving with edge computing (Cloudflare Workers, CloudFront Functions, Vercel Edge Runtime). You can run lightweight JavaScript at edge nodes to handle: A/B test routing, auth cookie validation, geographic redirects, and even server-side rendering. This moves more logic to the edge, further reducing origin load.
Interview Tip
In a design interview, as soon as you draw a web frontend, mention that all static assets go to a CDN. This signals awareness of real production architecture. Follow up by mentioning hash-based versioning and the immutable cache-control header — this shows depth beyond just 'put a CDN in front of it'. If the interviewer probes on cache invalidation, explain the hash-version approach eliminates the need for invalidation.