Akamai CDN architecture is three cooperating systems, not one: an edge network of roughly 4,100 server locations across 1,000+ partner networks, a DNS-based mapping system that re-scores those clusters continuously, and a tiered cache hierarchy that collapses origin fan-out. The decision that shapes both latency and delivery cost is the middle one. Akamai routes with DNS rather than anycast, and its low-level map responses typically carry a TTL of about 20 seconds. That buys per-client placement control and fast failure evacuation, at the cost of a longer resolution chain and a hard dependency on resolver locality.
The request path has more hops than a typical architecture drawing shows. Following one cold request end to end:
The mapping system is the part engineers under-model. It consumes liveness, load, throughput and end-to-end latency telemetry from the network, then solves a placement problem: put each client population on a cluster that minimizes latency subject to capacity headroom. The maps are recomputed on the order of tens of seconds to minutes, which is why "how Akamai CDN works" is better described as continuous re-optimization than as static geo-routing.
Akamai's mapping system resolves each request through a two-level DNS hierarchy whose low-level responses typically carry a TTL near 20 seconds, letting the platform shift traffic off a degraded cluster in about a minute. As of 2026 this remains the primary architectural split between Akamai's edge network and anycast-routed networks such as Cloudflare and Fastly, which move traffic by changing BGP announcements instead of DNS answers.
Tiered distribution exists because of fan-out, not because of hit ratio. A long-tail object with a 24-hour TTL requested from 40 distinct edge regions produces 40 origin fetches per day when edges talk to origin directly. Insert a parent layer and that collapses to the number of parents that saw the request.
Worked estimate, assumptions stated: 500,000 distinct objects fetched per day, 2 MB average object size, 24-hour TTL, 40 edge regions serving the audience, 8 parent clusters, cloud egress billed at $50 per TB.
| Configuration | Origin fetches per object/day | Origin egress/month | Egress cost/month (estimate) |
|---|---|---|---|
| Flat edge, no mid-tier | 40 | 1,200 TB | $60,000 |
| Edge plus 8 parent clusters | 8 | 240 TB | $12,000 |
| Edge plus single shield cluster | 1 | 30 TB | $1,500 |
For long-tail catalogs, the mid-tier's value comes almost entirely from reducing duplicate origin fetches, not from serving more bytes to users.
Diagrams show boxes and arrows; billing and p99 latency come from the details between them. Cache key normalization decides whether your 40 edge regions are storing one object or twelve variants of it. Request collapsing determines whether a cold hot object triggers one origin fetch or 3,000. Uncacheable responses bypass the tier entirely and pay full path cost every time.
You can reproduce the same fan-out collapse in front of your own origin. A minimal nginx mid-tier:
proxy_cache_path /var/cache/nginx/tier1 levels=2:2 keys_zone=tier1:512m
max_size=800g inactive=7d use_temp_path=off;
upstream origin_pool {
server origin1.internal.example:443 max_fails=3 fail_timeout=10s;
keepalive 64;
}
server {
listen 443 ssl http2;
location / {
proxy_cache tier1;
proxy_cache_key "$scheme$request_method$host$uri$is_args$args";
proxy_cache_lock on;
proxy_cache_lock_age 5s;
proxy_cache_valid 200 206 24h;
proxy_cache_use_stale updating error timeout http_500 http_502 http_503;
proxy_cache_background_update on;
proxy_ignore_headers Set-Cookie;
add_header X-Cache-Status $upstream_cache_status always;
proxy_pass https://origin_pool;
}
}The two directives that matter most are proxy_cache_lock, which collapses concurrent misses into one origin fetch, and proxy_cache_background_update, which keeps p99 latency flat during revalidation.
DNS mapping is precise but indirect. It steers the resolver, not the client, so accuracy degrades when users sit behind distant public resolvers unless EDNS Client Subnet (RFC 7871) is in play. Resolvers that ignore short TTLs also blunt the fast-evacuation property. Cold clients pay a multi-lookup resolution chain before the first byte, typically tens of milliseconds, amortized away by resolver and connection reuse.
Anycast inverts the trade: one address, no resolution chain, instant path selection, but coarse control and route changes you do not fully own.
Tiering costs one extra round trip on every miss, usually 5–30 ms intra-continent and considerably more across oceans. It also concentrates risk. A parent cluster is a correlated failure domain for every edge behind it, and a badly chosen shield location turns a 20 ms miss into a 180 ms miss. For high-popularity live streaming segments where edge hit ratio already exceeds 99%, a mid-tier adds latency and buys almost nothing.
The observability gap is fan-out. Most teams instrument edge hit ratio and stop there, so duplicate origin fetches stay invisible until the egress invoice arrives.
Akamai's mapping machinery earns its complexity for workloads with global, poorly-peered audiences, strict regulatory placement rules, and traffic that spikes unpredictably in specific networks. Its genuine strength is exactly that: granular, telemetry-driven placement that anycast cannot express.
If your audience is concentrated in a handful of regions and your cost driver is bytes rather than routing precision, that machinery is overhead you pay for. Cost-at-scale providers such as BlazingCDN reach comparable origin-offload results with an NVMe SSD edge and per-property cache and tiering rules, and its edge caching and origin offload features are configurable without a professional-services engagement; the trade-off is a smaller routing control surface than Akamai's edge network offers.
Akamai's edge network is primarily DNS-mapped rather than anycast-routed. A two-level DNS hierarchy returns edge addresses with short TTLs, typically around 20 seconds, so traffic can be re-pointed per client population within roughly a minute. Some Akamai services layer anycast on top, but the core mapping decision remains a DNS answer, not a BGP announcement.
Tiered Distribution places parent cache clusters between edge servers and origin. Edge misses are fetched from a parent instead of origin, so an object requested by 40 edge regions triggers a handful of origin fetches rather than 40. It reduces origin egress and origin load, at the price of one additional round trip on every miss.
The mapping system scores clusters using continuously collected liveness, load, throughput and latency telemetry, then assigns client populations to clusters that minimize latency within available capacity. Maps are recomputed on the order of tens of seconds to minutes. Inside the chosen cluster, the cache key is consistently hashed to select which machine owns the object.
No. Tiered caching reduces origin egress for long-tail catalogs where the same objects are fetched independently by many edge regions. For content that is already above roughly 99% edge hit ratio, such as popular live-stream segments, the mid-tier adds latency on misses and delivers negligible offload benefit.
Pull 24 hours of origin access logs and compute two figures: distinct object count and total origin requests. Divide. If the ratio is above 5, your delivery tier is duplicating fetches, and every duplicate is billed egress plus origin CPU. Then multiply the excess by your egress rate to get a monthly dollar figure for shield or mid-tier work. That single number decides whether tiering is an architecture project or a config change, and it argues better in a planning meeting than any hit-ratio chart.