A spare-parts catalogue loads slowly for dealers in another region. Product photographs and manuals keep coming from the central site even though they are identical for everyone. The same website also hosts private accounts, negotiated prices and contracts. Putting a CDN in front is straightforward. Treating all those responses as equally suitable for a shared cache is not.
Start by classifying the content. A public photograph is a good candidate for repeated delivery from a nearby copy. A personalised quotation requires access checks and a clear definition of who the response belongs to. Making delivery faster must not silently change those rules.
What the CDN actually moves closer
A content delivery network serves traffic through distributed locations. When a usable cached copy is available, a request need not travel all the way to the original server, usually called the origin. That can shorten the network path and remove repeated work from the central service.
A cache miss or required refresh still needs the origin. A CDN may also improve connections and delivery for uncacheable responses, but it does not remove application processing time. If the dealer is waiting for a complicated equipment calculation rather than photographs, the main delay may remain.
Edge computing adds the ability to run some logic at distributed locations: route a request, transform an image or check whether a request is permitted. It is a separate capability, even when sold alongside a CDN. Supported operations, data access and limits depend on the particular service.
The same URL may produce different answers
A price at one address may depend on language, currency, organisation or signed-in user. A cache key defines which requests count as equivalent. Leave out a meaningful difference and one dealer may receive another dealer's response. Include everything indiscriminately and copies stop being reusable, reducing the expected benefit.
Choosing the key is therefore part of designing the response. Public manuals, photographs and negotiated prices need different rules. Cloudflare's cache-key documentation illustrates how parameters, headers and other request characteristics can participate.
Separate keys do not replace authorisation. Even a correctly separated private file must not be served to someone without permission. Access must be checked on the serving path, and direct access to the origin must not bypass required restrictions.
Three similar settings mean different things
In HTTP, private prohibits storage by shared caches but may still allow a browser's private cache. no-cache permits storage but requires successful validation before reuse. no-store prohibits storage of the relevant response. These meanings are defined in RFC 9111; a dashboard label can easily invite the wrong interpretation.
Provider-specific rules can override ordinary behaviour, so test what is actually served rather than only what the application intended. Use two dealer accounts against the same URL and check that their private information remains separate. Repeat the test without signing in and after signing out.
No cache directive is a complete privacy mechanism. Authorisation, protected transport and the handling of an already downloaded document remain separate concerns. Revoking access cannot be reduced to a promise to purge a cache later.
Publishing an update without mixing versions
For immutable files, a content version in the filename is useful. A changed photograph or interface asset gets a new address, and the page starts referencing it. Older files may still be needed by pages that users already have open.
A document with a stable address needs a different lifecycle: freshness limits, validation and an explicit invalidation procedure when waiting is unacceptable. Purging a CDN does not automatically remove copies from a browser or corporate proxy. CloudFront's invalidation guidance explains this distinction and the alternative of versioned filenames.
Check error responses too. If a temporarily missing file produced a response that the CDN cached, uploading the file to the origin may not immediately fix the customer's result. Content and errors may need different caching and invalidation policies.
A cold cache sends work back to the centre
A popular catalogue may barely touch the origin during normal operation. After a broad purge or a release introducing new asset URLs, many requests need to fetch their original copies again. The central system must tolerate that state, not merely steady delivery from a warm cache.
Cache hit ratio alone is insufficient. Thousands of tiny icons and one large file have different effects on resources. Look at transferred bytes, origin requests, failures and the latency experienced by real users. Regional breakdowns matter too: an overall improvement can hide a group whose experience barely changed.
Serving an older public manual during an origin outage may be acceptable. Serving a withdrawn document or treating old equipment availability as current may not be. Stale-response policy should follow the user journey rather than a general preference to keep every page loading.
Moving code without its data may not help
If an edge function keeps calling the same distant database, moving the function closer to the customer does not guarantee a faster result. The company acquires another execution environment, permissions, logs and release procedures. Replicating data to the edge introduces freshness and consistency questions as well.
For this catalogue, begin with reusable public files. Measure ordinary delivery, an update and a cache miss. Include delivery, origin traffic, transformations and rule maintenance in the cost comparison. Moving private business logic is a separate decision: it should remove a demonstrated delay while preserving the access checks the product needs.