CDN and Network Optimization

A CDN changes the request path, not the source of truth

The origin remains authoritative even when the edge serves most reads. A cache purge changes derived copies; it does not replace the versioned source object, application state, or access-control decision.

The cache key is a correctness boundary

A cache key identifies the reusable representation. A typical key starts with scheme, host, path, and normalized query parameters, then includes only request dimensions that genuinely change the response.

Include a dimension when it changes the representation

• Asset version: a content hash or release identifier separates changed bytes.
• Language or encoding: include negotiated variants only when the response actually differs.
• Tenant or authorization class: separate private representations before shared caching; many authenticated responses should remain private instead.
• Query parameter: keep parameters that select content; drop tracking parameters that do not.
• Device class: vary only when the server emits materially different assets, not merely because the header exists.

Fragmentation is the opposite failure

Adding cookies, full user-agent strings, request IDs, or irrelevant query parameters can create a unique key for nearly every request. The configured TTL may be long, yet effective hit rate remains low because equivalent requests never meet in the same entry.

Trace failure through the actual delivery topology

An edge hit, a cold object, a fragmented key, and an origin timeout can all feel like “the CDN is slow.” The corrective action differs because each event activates a different path.

Keep data-plane and control-plane behavior separate

• The data plane serves requests using currently active routing, cache, certificate, and policy state.
• The control plane publishes configuration, invalidations, routes, and certificates to the data plane.
• A control-plane delay should not automatically stop healthy cached delivery.
• A purge or configuration rollout needs progress, failure, and rollback evidence across regions.
• Regional failover must account for the cold-cache pressure created at the destination.

Cache-hit rate is an origin-capacity multiplier

For cacheable request rate R and hit rate H, the first origin-load estimate is:

origin requests per second = R x (1 - H)

At 100,000 requests per second, moving from a 95% hit rate to 90% doubles origin demand from 5,000 to 10,000 requests per second. Percentage points that look small on a dashboard can be a large absolute capacity event.

The origin model should include more than average request count:

• peak demand and regional concentration;
• cold-start and invalidation bursts;
• shield hit rate and request coalescing;
• origin latency, concurrency, and connection limits;
• object size and egress bandwidth;
• retries, timeout budgets, and stale fallback eligibility.

Plan the miss path as a production path, not an exceptional path. A CDN configuration that works only while the cache is warm has no safe recovery state.

Freshness is a product decision

HTTP caching distinguishes how long an object is fresh from what a cache may do after freshness ends. The correct policy depends on how costly stale data is and how quickly a new version must become visible.

Invalidation is not the default versioning strategy

Purges are useful for emergency removal and bounded mutable objects, but they are distributed control-plane operations. They can be delayed, partially applied, rate limited, or issued with an incorrect scope. Prefer versioned URLs for immutable assets and measure purge completion when invalidation is required.

Network latency has multiple budgets

“Edge latency” is not one number. A viewer may pay DNS resolution, transport setup, TLS, request travel, edge processing, cache lookup, origin fetch, and response transfer. Connection reuse and modern transports can remove repeated setup work, but they cannot make a distant miss behave like a local hit.

1. 1

   DNS

   Resolve and route

   Map the hostname to a healthy edge route. Respect TTL and failover behavior instead of assuming every resolver changes immediately.

2. 2

   Connect

   Establish transport

   Negotiate TCP plus TLS or QUIC, then reuse the connection where possible. Loss and path changes affect the setup cost.

3. 3

   Cache

   Make the edge decision

   Authenticate as required, normalize the key, check freshness, and choose hit, stale, revalidation, or miss behavior.

4. 4

   Deliver

   Fetch and transfer

   Reach the shield or origin on a miss, then transfer bytes under the remaining deadline and populate only safe responses.

HTTP/2 multiplexes streams over one connection but can still suffer when packet loss blocks progress at the TCP layer. HTTP/3 maps HTTP onto QUIC streams so loss on one stream does not impose the same cross-stream transport blocking. Actual benefit still depends on network conditions, implementation, connection reuse, and workload.

Choose a CDN from workload constraints

Provider branding is less useful than a decision contract. Compare the behavior your workload must prove.

Run a representative test with your object sizes, cacheability mix, countries, protocols, and miss behavior. A published point-of-presence count or best-case latency does not prove that a specific request path meets its target.

Operate the edge with outcome evidence

Monitor the full distribution and the reason behind each outcome:

• Cache outcomes: hit, miss, stale, revalidated, bypassed, and error by route and safe key dimensions.
• Age and freshness: object age at serve time and time spent outside the intended policy.
• Origin pressure: request rate, bytes, concurrency, shield efficiency, timeout, and retry amplification.
• User latency: DNS, connection, time to first byte, and transfer time by region and protocol.
• Correctness: authorization leakage tests, wrong-variant reports, purge completion, and stale-policy violations.
• Resilience: regional failover time, cold-cache recovery, stale fallback use, and origin saturation.
• Cost: edge egress, origin egress, request classes, invalidations, and compute at the edge.

Use a synthetic probe for known paths, but correlate it with real-user measurements and server-side cache status. One fast probe from a major city cannot represent a global network.

Primary references

• RFC 9111: HTTP Caching
• RFC 9114: HTTP/3
• RFC 9000: QUIC
• RFC 9211: Cache-Status