Edge Computing and CDNs: How They Actually Work

A CDN is two unglamorous mechanisms wearing a marketing name: an IP address announced from many places at once, and a cache key. Almost every real-world CDN problem is a misconfiguration of the second one, and almost every disappointing edge-compute migration is a misunderstanding of what the first one can do for a request that has to reach your database anyway.

Here is how both actually work, with published numbers from Cloudflare, AWS and Fastly as of September 2026, and an honest account of the cases where moving code closer to users makes things slower.

Anycast, and why one IP has hundreds of homes

Cloudflare defines anycast as “a network addressing and routing method in which incoming requests can be routed to a variety of different locations or ‘nodes’.” Under unicast, one address maps to one machine. Under anycast, the same address is announced from every point of presence, and internet routing delivers each packet to whichever announcement is closest in network terms. Nothing in your DNS or your application changes. The routing table does the work.

This is why a CDN is also a DDoS absorber: attack traffic lands distributed across the whole fleet rather than converging on one target. Cloudflare is candid about the operational cost, noting that proper anycast “requires that a CDN provider maintains their own network hardware, builds direct relationships with their upstream carriers, and tunes their networking routes to ensure traffic doesn’t ‘flap’ between multiple locations.”

Two opposite PoP strategies

Providers disagree about whether to build many small sites or few large ones, and both publish enough to see the difference.

More PoPs is not automatically better. Each additional cache location fragments your working set, so the same object gets fetched from origin once per location that needs it. That is precisely why CloudFront layers 15 regional edge caches and an Origin Shield behind its edge, with the documentation claiming Origin Shield “optimizes cache hit ratios and collapses requests across regions leading to as few as one origin request per object.” Fastly’s answer to the same physics is to have fewer, denser sites in the first place.

Cache keys are the whole game

A cache key is the string a CDN uses to decide whether it has seen this request before. Cloudflare’s default key is the full URL (scheme, host and URI including query string), plus the client’s Origin header for CORS correctness and forwarding headers such as x-forwarded-host. You can add or remove components: specific query-string parameters, headers, cookies (by value or by presence), the original versus resolved host, a device-type classification of mobile, desktop or tablet, and client country or Accept-Language. Advanced cache key customisation requires an Enterprise plan; the lower tiers get basic options such as ignoring query strings and device-type classification.

AWS structures the same idea as a cache policy, where you specify which headers, cookies and query strings CloudFront includes, along with TTLs and compression behaviour. Its cache-key documentation states the rule that governs every cache-key decision: “Including fewer values in the cache key increases the likelihood of a cache hit.”

Cardinality, with numbers

Cache key components multiply. Take a marketing page and add three things to the key: device type (3 values), a country header (say 40 countries you serve), and an Accept-Language header (5 languages). One URL now has 3 × 40 × 5 = 600 possible cache entries. Serve 10,000 requests a day for that URL and the average entry sees about 17 hits, spread across every PoP that receives traffic. Objects that thinly used get evicted before they are reused, and your hit ratio collapses toward zero while your origin bill climbs. The discipline is to keep the key as narrow as the response genuinely varies, and to move personalisation into a separate uncached fetch rather than into the key of a document that is 95% identical for everyone.

Invalidation: version files, do not purge them

CloudFront’s invalidation pricing is a useful forcing function. AWS gives you no charge for the first 1,000 paths or tags requested for invalidation each month, then $0.005 per path or tag. A wildcard counts as a single path regardless of how many files it clears, so /* costs the same as /images/logo.jpg. Tag invalidations draw on the same 1,000-path allowance, and bundling paths into one API request does not reduce the count.

Worked example: a deployment pipeline that purges 200 individual asset paths on every release and ships 30 times a month issues 6,000 invalidation paths, of which 5,000 are billable, for $25 a month. Replace those 200 paths with a single /* per release and it costs 30 paths, inside the free allowance, at the price of a brief global cache miss. AWS’s own documentation prefers a third option and recommends versioned file names, because you never pay for invalidation and you get deterministic cache behaviour instead of eventual purge propagation.

Edge compute runtimes, and their real constraints

Edge functions are not small servers. Cloudflare’s documented Workers limits are specific: 128 MB of memory per isolate including the JavaScript heap and any WebAssembly allocations; 10 ms of CPU per request on the free plan against a 30-second default and 5-minute maximum on paid; script size of 3 MB gzipped on free and 10 MB gzipped on paid, with a 64 MB uncompressed ceiling; up to six connections at a time waiting for response headers. Fastly’s Compute documentation describes a fresh instance created per request, with per-request isolation and lightweight sandboxing, billed against a 128 MB minimum memory allocation.

Those numbers rule things in and out cleanly. Header rewriting, auth token validation, A/B assignment, geo-routing, request coalescing, HTML rewriting and personalised fragment assembly all fit. Image transcoding of large files, anything needing a native binary or a thread pool, long-lived stateful connections, or a dependency tree that gzips past 10 MB do not.

When the edge does not help

The clearest statement of the problem comes from Cloudflare’s own product for fixing it. Smart Placement exists because, in Cloudflare’s example, “a user in Sydney, Australia accessing an application running on Workers… makes multiple round trips to a database in Frankfurt, Germany.” Running that Worker in Sydney makes the first hop short and every database round trip intercontinental. Running it beside the database in Frankfurt pays the long hop once and makes the round trips local, which Cloudflare says “reduces the total request duration.” Cloudflare’s system analyses request duration across candidate locations, needs consistent traffic from multiple locations, takes up to 15 minutes to decide, and deliberately leaves 1% of requests unplaced as a baseline.

A short checklist before you move anything to the edge

1. Measure your current cache hit ratio per content type. If static assets are below roughly 90%, fix the cache key before buying anything.
2. Count the components in your cache key and multiply their cardinalities. If the product is in the hundreds for a single URL, that is your problem.
3. Count origin round trips per request. Two or more against a single-region datastore means compute belongs near the data, not near the user.
4. Check the response against the runtime ceilings: 128 MB of memory, single-digit or low-tens-of-milliseconds of CPU, a compressed bundle within limits.
5. Replace purge-on-deploy with content-hashed filenames, and keep wildcard invalidation as the emergency lever rather than the routine one.

All published figures here were retrieved in September 2026 and providers revise footprint and pricing numbers regularly; check the vendor page before putting any of them in a business case.

Sources

• Cloudflare — What is Anycast?
• Cloudflare — The Cloudflare global network
• Amazon Web Services — Amazon CloudFront features
• Fastly — Network map
• Cloudflare Docs — Cache keys
• AWS Documentation — Paying for file invalidation
• Cloudflare Docs — Workers limits
• Cloudflare Docs — Smart Placement