The Moment Before the First Frame Loads

You hit play. The screen sits there, blank. Somewhere in the next 200 milliseconds, a content delivery network runs a multi-factor selection process, picks one specific server out of potentially thousands, and routes your request to it before you've registered that anything needed to happen. The whole thing is over before you notice.

Here's what actually happened.

Not Just the Closest Box in the Room

The most persistent myth about CDNs is that they simply hand you the geographically nearest server. Proximity matters, sure. But a CDN treating distance as the only variable would be about as useful as a GPS that ignored traffic, road closures, and speed limits and just drew you a straight line to your destination.

Real CDN routing layers at least four signals on top of each other.

Network distance, not physical distance. A server 800 kilometres away on a direct fibre backbone can respond faster than one 200 kilometres away on a congested regional link. CDNs measure round-trip time constantly, and a 12ms RTT beats a 40ms RTT regardless of where the hardware sits in a warehouse.

Server load and capacity. Every edge node reports its current CPU load, active connection count, and available bandwidth. A node running at 90% throughput gets deprioritised even if it's geographically ideal. No point shovelling more water into an already-full bucket.

Cache state. This one is underrated, and most explanations skip it entirely. If Server A already has your specific video segment sitting in its RAM, it serves it almost instantly. Server B, three milliseconds closer by RTT, might have to fetch that segment from the origin server first, adding 80 to 200ms of latency. The CDN knows which nodes have which content cached, and it factors that in.

Health checks. Edge nodes report their status every few seconds. A node with elevated error rates, packet loss above roughly 1 to 2%, or a recent spike in failed requests gets pulled down the priority list automatically. The CDN is not going to send you to a node that's been quietly failing 5% of connections.

The Actual Mechanism: DNS and Anycast

Most CDNs make the routing decision at the DNS resolution layer. When your device asks "where is this video?", the CDN's authoritative DNS server doesn't return a static IP. It runs its routing logic right then, in real time, and returns the IP of whichever edge node currently wins the multi-factor score. The whole DNS lookup takes 20 to 80ms. The server selection happens inside it.

Some CDNs use anycast routing instead, where dozens of servers share a single IP address and the internet's own routing infrastructure (BGP, the Border Gateway Protocol) delivers your packets to whichever node is topologically closest at that moment. Cloudflare uses anycast heavily. The selection logic is baked into how internet routers propagate paths, not into DNS.

Neither approach is strictly better. DNS-based routing lets the CDN apply richer application-level logic. Anycast responds faster to sudden network changes. Large CDN operators often use both, in different layers of the same request.

A Worked Example: Two Viewers, One Video

Imagine two people watching the same documentary. Priya in Manchester and Tobias in Munich.

Priya's request resolves to a CDN edge node in Amsterdam. That node has her video cached from an earlier viewer, reports a 14ms RTT from her ISP's handoff point, and is running at 60% load. Her first segment arrives in under 200ms.

Tobias's request hits the same DNS system a minute later. The Amsterdam node now has a backlog: a live sports event spiked its connections. The CDN's scoring drops Amsterdam in Tobias's result. Frankfurt scores better right now, 18ms RTT from his provider, 45% load, and it already cached the first four minutes of the documentary from another German viewer. Tobias gets Frankfurt. His first segment takes 240ms.

Neither of them notices the difference. The CDN made two different decisions for the same content, 60 seconds apart, and both were correct.

What People Get Wrong About Buffering

Once your video is playing, the initial server selection isn't the only thing keeping it smooth. Modern streaming protocols (HLS and DASH are the dominant ones) break video into small segments, typically 2 to 6 seconds long, and your player requests each segment independently. The CDN can theoretically route segment 47 to a different edge node than segment 46 if conditions changed.

In practice, players and CDNs try to stick with one node per session to avoid reordering headaches. Still, the system is designed to switch. If your chosen node starts degrading mid-stream, a well-built CDN and player combination detects the rising latency and re-requests from a healthier node. Buffering usually means that failover didn't happen fast enough, or the whole regional cluster was struggling. Not that one server had a bad moment.

And here's the opinion worth stating plainly: blaming your home internet speed for buffering is almost always wrong. A 100 Mbps connection streaming a 15 Mbps 4K feed has headroom to spare. The actual culprit is usually a congested link somewhere between the CDN edge node and your ISP's last-mile infrastructure, which is outside both your control and the CDN's direct control. The CDN can pick a better-connected node. It cannot repave the road between its exit and your front door.

The Score That Never Stops Updating

The selection logic described above isn't a one-time configuration. CDN operators run continuous synthetic monitoring: automated probes that mimic real user requests from different network vantage points, measuring RTT, throughput, and error rates every 30 to 60 seconds across thousands of node pairs. That data feeds back into the routing weights in near real time.

So here's the question worth sitting with: if you've ever noticed your stream quality quietly improve a few seconds after it started struggling, do you know what you were watching? The CDN noticed the degradation, the player re-requested, and a different node picked up the slack. You saw the system do its job.

This is why CDNs with denser networks of edge nodes consistently outperform smaller ones, even when both have a node in your city, and that's not a close call. More nodes means finer-grained selection, more likely cache hits, and more fallback options when one cluster has a bad afternoon. The intelligence is real. But it only works as well as the physical footprint underneath it.