A CDN places delivery points near consumers and can reuse responses without repeating the journey to the origin. It reduces latency and origin work when responses are cacheable. It also introduces distributed copies with identity, freshness, and access rules that must be part of the product contract.
A public image and a private document need different policies even if both are files. Design starts with what can be shared, with whom, for how long, and which path serves misses.
Cache key: response identity
The cache key determines which requests can reuse the same entry. It usually starts with the host and path, and may include selected query parameters, headers, or cookies. HTTP method, compression variants, language, and any other data that changes the result must be handled according to CDN capabilities. Seeing the same path in two URLs is not enough.
For example, /report returns different content for each authenticated tenant. If that response enters a shared cache without correct identity isolation, another user could receive it. Including a header in the key only helps if its value comes from a trusted identity and access is validated; it does not replace authorization. For private content, the prudent starting point is to avoid shared caching unless an explicit, verified contract exists.
Overly broad keys may mix responses. Overly specific keys fragment the cache: including every cookie or tracking parameter reduces reuse and increases misses. Distinguish data that changes the response from data that only needs forwarding to the origin. Cache-key and forwarding policies need review together.
Hits, misses, and the origin
--- config: look: handDrawn --- flowchart TD client["Client"] --> edge["CDN edge<br/>Access and cache-key policy"] edge --> fresh{"Reusable entry?"} fresh -->|"Hit"| response["Deliver permitted response"] fresh -->|"Miss or revalidation"| protect["Bounded origin access"] protect --> origin["Origin<br/>Authorization and content"] origin -->|"Cacheable response + validators"| fill["Store selected variant"] fill --> response response --> client release["Versioned asset release"] -->|"New URL"| edge purge["Invalidation request"] -.->|"Propagation must be observed"| edge
The origin remains responsible for authorization and content. It should prevent direct access that bypasses intended edge controls when the architecture requires that perimeter; the mechanism depends on the service. A hard-to-guess URL is not an access control.
A miss adds the origin journey and may occur at many points of presence simultaneously. A shield, request collapsing, or intermediate cache can reduce that fanout, depending on the product. It also needs concurrency limits and a failure policy: a broad purge or cache-cooling deployment must not saturate the origin.
TTL, validators, and older content
HTTP headers describe rules such as max-age, s-maxage, private, and no-store; a CDN may impose additional limits or policies. Verify the actual combination. private tells shared caches not to store the response; no-store requests that it not be stored. Neither header automatically deletes a copy already distributed under a different policy. In CloudFront, a minimum TTL greater than zero may override even private, no-store, or no-cache; it must be zero to respect those origin directives.
The TTL limits when an entry can be reused without revalidation under that policy. It does not prove that the origin has not changed. A response generated from older data may receive a new TTL. Validators such as ETag support conditional requests, but require the origin to represent the content version and its variants correctly.
stale-while-revalidate may allow an older copy while it refreshes; stale-if-error may allow it during certain failures. Both require product-approved staleness windows and verified support. Price, inventory, and permissions must not depend on a copy when the operation requires current-state validation. The availability view and seat reservation illustrate this separation.
Versions and invalidation
For assets that truly remain immutable, a versioned or hashed path such as /assets/app.<hash>.js lets a release publish a new URL without waiting for the previous version to disappear. The hash must match the content, and the previous object must retain its bytes. Changing content under that same URL breaks the assumption. The document referencing those versions needs its own freshness policy.
Invalidation requests removal of existing entries. Treat it as a distributed operation whose result and propagation must be observed. API acceptance does not prove that every consumer has stopped using a copy: browser caches, proxies, or previously delivered responses may remain. If the API response is lost, query or reconcile its status before assuming success or absence of the operation.
A race between an old fill and invalidation also needs testing. The provider’s contract determines how those events are processed; a purge must not be assumed to make an origin update atomic. Sensitive removal needs an access or revocation mechanism compatible with the requirement, as well as observed purge behavior.
CloudFront may retain private content in edge cache if it validates the signed URL or policy before serving it. This requires configuring access and cacheability as separate decisions, without mixing personalized responses. Signed URLs or signed cookies may restrict access when the product validates them. Define their expiration, keys, and possible revocation. Copying a link lets another person use the capabilities it contains while it remains valid, unless additional controls apply. Versioning or invalidating its path does not replace that access model.
What to verify
Compare requests that differ in language, tenant, authorization, cookies, and relevant parameters. None should reuse an incompatible response. Also verify direct origin access, a failure with a cold cache, and behavior when the origin returns errors.
Useful signals include hit ratio by route and variant, delivered bytes, consumer latency, origin requests and concurrency, errors, and response age. Aggregate hit ratio may hide expensive routes with many misses. Economic evaluation needs those units and actual transfer and request costs.
A release exercise should update the document and its assets, observe an invalidation, and check clients using a previous version. The expected result specifies which older content remains valid and how the service recovers without overloading the origin.