Static Content Hosting

## The mechanism The mechanism has two moving parts working together. 1. **First, the static files** — images, compiled CSS, JS bundles, fonts, videos — are uploaded to an **object storage** service (Amazon S3, Google Cloud Storage, Azure Blob Storage) rather than bundled into the application's deployment artifact or served from its local disk. Object storage is a flat key-value store for immutable blobs: durable, horizontally scalable, and priced for storage plus egress rather than compute time. 2. **Second, a CDN** (CloudFront, Cloudflare, Fastly, Akamai) is placed in front of that storage as a distribution. The CDN operates dozens to hundreds of **edge points of presence (PoPs)** around the world. When a client requests a file, DNS or anycast routing sends the request to the nearest PoP. - **Cache hit** — if that PoP already has a cached copy within its TTL, it serves the file directly, with no trip to origin at all. - **Cache miss** — if not, the PoP pulls the file from the object storage origin once, caches it according to the response's `Cache-Control` header, and serves it to the client. Every subsequent request to that PoP is now a hit. ## Why the app tier is the wrong tool This exists because application servers are the wrong tool for this job. - A typical app server process is provisioned around handling business logic — database queries, authentication, computation — and its capacity is measured in requests-per-second of that kind of work. - Streaming a 2MB JS bundle ties up a worker thread, a socket, and outbound bandwidth for the whole transfer, capacity that isn't then available for the requests the app tier actually exists to handle. - Worse, the app tier typically runs in one or a few regions, so every user, regardless of geography, pays the round-trip latency to reach it. Static assets don't need any of the app tier's request-handling machinery; they're just bytes that don't change per request. Splitting them out to storage-plus-CDN lets each system do only what it's optimized for. ## The trade-offs The trade-offs cut in both directions. - **On the cost side**, CDN egress and object storage are usually priced well below compute-tier egress, and offloading the bulk of asset traffic — often the majority of a website's byte volume — away from origin can meaningfully cut both bandwidth and compute-scaling costs. - **Latency** for cache hits is excellent because the edge PoP is topologically close to the user, versus routing every request back to a centralized origin. - **The cost is operational:** you now run two additional pieces of infrastructure — a storage bucket and a CDN distribution — each with its own configuration, access policy, and monitoring. You also trade strong consistency for **eventual consistency**: once a file is cached at the edge, updates to the origin copy won't be visible to users hitting that PoP until the TTL expires or a purge is issued. Deploying a new version of a static asset isn't instantaneous the way updating an app-server response would be. ## Failure modes in production That eventual-consistency trade-off is also the main source of failure modes in production. 1. **Stale-asset bugs after a deploy** — the most common. A team ships a new CSS file under the same filename, but users behind edge caches keep receiving the old bytes for hours until TTL expiry, causing visual breakage or, worse, an HTML page referencing a JS chunk that the old cached bundle doesn't contain (a classic 'chunk load failed' error during rolling frontend deploys). The standard fix is cache-busting — putting a content hash or version number in the filename itself so a new build produces a new URL, and setting a long, `immutable` `Cache-Control` on those hashed files while keeping the entry HTML uncached or short-TTL so it always points at the latest hashed assets. 2. **A cold-cache stampede** — a second failure mode. If a purge invalidates a popular asset across every PoP simultaneously, all of them miss at once and hammer origin concurrently, which can look like a self-inflicted DDoS. 3. **Misconfiguration** — a third. Forgetting CORS headers on cross-origin font or module loads causes silent browser-side blocking, and an overly permissive bucket policy can leak non-public files stored alongside legitimately public assets. ## Where it shows up A concrete, widely used pattern is a modern frontend build pipeline (webpack/Vite output) publishing hashed JS/CSS bundles to an S3 bucket behind CloudFront, with a long, `immutable` `Cache-Control` on the hashed assets and a `no-cache` policy on `index.html`, so browsers and the CDN cache the bundles essentially forever while every deploy is picked up immediately through the always-fresh entry document.