CDN

If every user in the world has to fetch static assets directly from a distant origin server, distance becomes latency and popularity becomes origin load. A user far from the origin may wait on round trips that have nothing to do with application logic, and a globally popular file may be sent from the same source again and again even though the content has not changed. That is wasteful for both performance and infrastructure cost. It also creates a concentration risk, because a single origin region can become both a bottleneck and a failure point. CDN addresses this by changing where repeated content is served from, not just by making the origin stronger.

As internet usage spread globally and assets such as images, scripts, downloads, and media grew heavier, the old model of serving everything from a single origin became increasingly inefficient. Bandwidth was costly, server capacity was finite, and spikes in popularity could overwhelm origin infrastructure. Distributed cache networks emerged as a way to absorb repeated demand closer to users. Over time, CDNs expanded beyond static acceleration into areas such as DDoS absorption, dynamic optimization, and edge execution. But the original reason they mattered has not changed: they reduce the penalty of distance and repetition in global content delivery.

A CDN places edge servers in many geographic locations and stores cacheable origin content close to where users are. Requests are steered toward a nearby edge through mechanisms such as DNS-based routing and Anycast. If the requested object is already cached there, the edge can respond immediately without touching the origin. If not, the edge fetches the object from the origin, returns it to the user, and stores it according to cache policy for future requests. That means CDN behavior is shaped not only by geography but also by cache-control rules, TTLs, and invalidation strategy. A CDN is therefore not just a distributed copy of files; it is a distributed decision layer for when the edge should answer and when the origin still must.

CDN and load balancer can both appear at the front of traffic flow, but they solve different classes of problems. CDN reduces geographic latency and repeated origin work by serving cacheable content from distributed edges. Load balancing spreads requests across multiple backend instances that are usually part of the same service region or deployment boundary. One answers 'where should this content be served from for speed and scale?' while the other answers 'which backend should handle this request among healthy replicas?' Large systems commonly use both because global delivery optimization and backend distribution are complementary, not competing, concerns.

CDNs are especially effective for images, videos, stylesheets, scripts, software packages, and globally accessed websites where many users request the same or similar content. They can improve startup performance, offload origin traffic, and make traffic spikes far easier to absorb. Their value is lower when responses are highly personalized, heavily authenticated, or constantly changing in ways that defeat caching. In those cases, cache policy design becomes more important than simply enabling a CDN. Using a CDN well means drawing a clean boundary between content that should live at the edge and content that still needs origin truth for every request.