Content delivery network

RFC 9111 defines the caching rules: a response is fresh for a stated lifetime, and after that the cache revalidates. The CDN is a shared HTTP cache with its own servers, not a second bucket the sender uploads to by hand.

The origin still holds the object. The first fetch in a region misses, pulls from origin, and stores the response. Later fetches hit. That is why a popular public file does not melt one server. It is also why a replaced file can keep circulating. If the cache key is the URL and the lifetime is an hour, the old bytes keep moving until the object is purged or the lifetime ends. Uploading a new object to the same key does not, by itself, push the new bytes to every edge.

A release server puts `installer-4.2.dmg`, 1.8 GB, behind a CDN. The first customer in Singapore waits on the origin pull. The next fifty in that city finish from the edge, and the origin graph stays flat. At 14:00 the build is pulled for a bad signature. The bucket key is overwritten. Edges that cached the URL still serve 4.2 until purge. A revoke that only deletes the origin object loses to those edges unless someone sends a purge on that URL. Private files are a poor default for a shared cache. A CDN that caches a URL with no Vary on the authorization header can hand one user's download to the next requester of the same path.

A CDN is not object storage. The bucket is the system of record. The CDN is a copy optimized for GET. Uploads almost always go to the origin. Counting CDN traffic as "downloads of the file" double-counts if you also count origin GETs, and under-counts if the edge served the hit and the origin never saw it.