Serving every byte from one origin means every user pays the full round-trip distance to that building. A user in Sydney fetching from Virginia waits ~200 ms per round trip before a single byte of content moves — and a page needs dozens of round trips. Content delivery networks attack the distance itself, and anycast routing attacks the problem of finding the nearest copy.
Edge caches serve content from nearby locations
A CDN is a globally distributed network of edge servers that cache content close to users. When a user requests a resource, the CDN serves it from the nearest edge location rather than the origin server, reducing latency and offloading the origin. A provider with 300+ points of presence puts most users within 20–30 ms of an edge, turning that 200 ms Sydney-to-Virginia fetch into a local one.
How a request finds the nearest edge
- User resolves a CNAME — e.g.,
cdn.example.commight resolve toedge-01.lax.cdnprovider.net. - DNS returns an edge location — the resolver answers with the IP of the edge server that is cheapest to reach, using the resolver's location, BGP path costs, and current load.
- Edge cache lookup — the edge server checks its cache. If the content is there (a cache hit), it serves it immediately with no origin traffic at all.
- Cache miss — the edge server fetches from the origin (or a parent edge), caches it, and serves the user. Subsequent requests hit the cache.
Expiry and purging bound staleness
CDNs use TTL (time-to-live) to determine how long to cache content. After the TTL expires, the next request triggers a fresh fetch from origin. A one-year TTL on fingerprinted assets (app.a3f9c2.js) is safe because the name changes with the content; a 60-second TTL on an API response bounds staleness to a minute. For content that changes unpredictably, invalidation APIs purge the cache proactively — typically effective worldwide within seconds, though providers charge per purge beyond a free quota.
Anycast sends packets to the nearest identical address
Anycast is a network addressing and routing strategy where the same IP address is assigned to multiple servers in different locations. When a client connects to an anycast address, BGP routes the connection to the "nearest" server (by hop count, not geographic distance). DNS root servers and major CDN entry points all use anycast: one address, dozens of replicas, and the routing fabric picks the closest.
When to use anycast versus DNS-based steering
| Anycast | CDN (DNS-steered) | |
|---|---|---|
| Routing | BGP selects the nearest replica | DNS returns the nearest edge server |
| Content | Same IP, same service | Edge servers cache specific content |
| Use case | DNS root servers, CDN entry points | Web assets, videos, API responses |
Anycast is often combined with CDNs: an anycast address serves as the entry point, and the edge server then serves cached content. The combination covers both halves — anycast absorbs the routing decision and DNS steering handles capacity-aware load balancing. Anycast failover is also automatic: if an edge site goes dark, BGP withdraws its announcement and traffic shifts to the next-nearest replica with no DNS TTL to wait out.
Compute at the edge removes the origin round trip
Modern CDNs extend beyond caching — they run compute at the edge. Edge functions execute application code (authentication, A/B testing, image resizing) at the edge location, eliminating a 100+ ms origin round trip per request. A personalization check that ran at the origin on every page view becomes a sub-millisecond edge lookup against a replicated key-value store — at the cost of an execution model with strict CPU and memory limits (typically 50 ms wall-clock and 128 MB) and eventual consistency on replicated state.
Where the latency savings show up
A well-configured CDN cuts 50–90% of latency for cacheable static content: a 1.2 MB bundle served from 25 ms away instead of 220 ms away finishes roughly 10 round trips sooner. Dynamic content improves less (20–50%) because the origin still does the work — the gain is the shorter client-to-edge leg plus connection reuse. The first byte time (TTFB) is dominated by the TCP and TLS handshake cost, which is why connection reuse and TLS 1.3 resumption (including 0-RTT, inherited by QUIC and therefore usable by HTTP/3) matter most on exactly the long-distance paths CDNs shorten.
Where this bites in production
- Cache-hit ratio is the metric. Below ~90% for static assets, the CDN is decoration — check Cache-Control headers and query-string cache-busting before buying more edge.
- Stale-while-revalidate hides origin slowness. Serving a slightly stale copy instantly while refreshing in the background keeps p99 flat during origin incidents; without it, every origin hiccup becomes user-facing.
- Anycast and state do not mix. Anycast routes each packet independently, so a mid-connection route change lands on a different server. Keep anycast endpoints stateless and push session state to a shared store or a sticky layer above.
Read: HTTP/2 Multiplexing · Review: TCP Transport
Production cost model and latency numbers
To apply CDNs and Anycast Routing effectively in production systems, engineers must move beyond qualitative diagrams and quantify the exact hardware and network costs at each boundary:
| Operation / Boundary | Typical Latency | Dominant Bottleneck | Production Mitigation |
|---|---|---|---|
| L1 / L2 Cache Access | 1 ns – 4 ns | Register dependency chains & pointer chasing | Contiguous memory layouts, cache-line alignment (64 B), and batch iteration |
| Main Memory (DRAM) Fetch | 60 ns – 100 ns | TLB misses, random heap indirection, NUMA hops | HugePages (2 MB), arena/slab allocators, and pre-allocated ring buffers |
| Kernel Syscall / Context Switch | 1 µs – 5 µs | User-to-kernel mode switch, page-table flush, lock contention | Non-blocking readiness loops (epoll / io_uring), batching, and zero-copy I/O |
| NVMe SSD Random Read / fsync | 50 µs – 500 µs | Block I/O queue depth, write amplification, WAL flushes | Group commit, sequential append logs, and bounded buffer-pool pinning |
| Intra-Region RPC Roundtrip | 0.5 ms – 2.5 ms | Serialization, TCP/TLS framing, tail queueing ($L = \lambda W$) | Connection pooling, deadline propagation, and p95 hedged requests |
Failure modes, debugging, and operational checklist
In real incidents, systems rarely fail at average (p50) load—they fail when a slow dependency, skewed hot key, or resource leak pushes concurrency across a non-linear saturation cliff. When reviewing code or architecture that relies on CDNs and Anycast Routing, walk through three verification questions:
- What is the invariant under partial failure or contention? If a worker crashes mid-operation, a network packet is delayed and reordered, or two threads race on the same state transition, prove which atomic primitive, version number, or idempotency key prevents silent corruption.
- How is backpressure enforced when demand exceeds capacity? Unbounded in-memory queues, unthrottled retries, and blocking calls without explicit deadlines turn a localized
100 msslowdown into a fleet-wide Out-Of-Memory (OOM) cascade. Always bound queue depths, propagate caller deadlines, and shed excess load early. - Which metrics and traces isolate the bottleneck in under 60 seconds? Instrument saturation, queue wait time vs service execution time, cache hit/miss ratios, and error rates by failure reason so on-call engineers can immediately distinguish a compute bottleneck from an I/O or lock-contention stall.