For most of the web’s history, a CDN did one job: cache static assets like images, video, and JavaScript bundles at points of presence around the world so users didn’t have to fetch them from a single origin server on the other side of the planet. That’s still a huge part of what CDNs do. But somewhere along the way, the same infrastructure that made caching fast turned into a place where developers now run actual application logic. Understanding why requires looking at what a CDN’s point of presence actually is, and why it turned out to be a good place to put compute.

The Caching Layer Was Already Doing More Than Caching

Even a “simple” CDN was never just a dumb cache. Every request that hits an edge node passes through logic that decides whether to serve a cached copy, revalidate it, or forward the request upstream. That decision layer needed to be programmable almost from the start, first through configuration rules, then through scripting hooks that let customers rewrite headers, redirect requests, or apply access rules without a round trip to origin.

Once a CDN vendor exposes a scripting hook at the edge, the natural next question from customers is “can I run more of my own code here?” A/B testing logic, authentication checks, request routing, and image transformation are all things that benefit from running as close to the user as possible rather than at a centralized origin. The scripting hook grows into a runtime, and the runtime grows into a platform.

Why the Edge Is a Good Place to Run Code

The case for edge compute rests on a few durable technical realities:

• Network latency is bounded by physics. No amount of server optimization removes the time it takes for a packet to cross an ocean. Running logic physically closer to the user cuts that time for anything that doesn’t need a database round trip anyway.
• Many requests are cheap to handle and don’t need a full application server. Redirects, header manipulation, simple personalization, and request validation are exactly the kind of workloads that make sense to push outward.
• Origin servers benefit from having fewer requests to handle. Filtering, rejecting, or resolving requests at the edge reduces load on centralized infrastructure, which is good for both cost and resilience.

The tradeoff is that edge runtimes are deliberately constrained. They typically run in lightweight sandboxes, often based on isolate technology similar to what browsers use to separate tabs, rather than full containers or virtual machines. That gives fast cold starts and tight resource limits, which is great for short-lived request handling but a poor fit for long-running processes or workloads with heavy dependencies.

The New Constraints Developers Run Into

Building for the edge means accepting a different set of rules than a traditional backend. Execution time is capped, often in the range of milliseconds to a few seconds. Available APIs are a subset of what a full server runtime offers, since the sandboxing model that makes edge functions fast and cheap also limits filesystem access and long-lived state. And because code runs in hundreds of locations instead of a handful of regions, anything stateful, like a database write, still has to talk back to a centralized system, which reintroduces the latency the edge was supposed to avoid.

This is why edge compute has settled into a fairly specific niche rather than replacing traditional backends. It’s well suited to routing decisions, authentication checks, lightweight rendering, and request transformation. It’s a poor fit for anything transactional or dependent on a large, consistent dataset.

Where This Leaves the Architecture Conversation

The practical effect is that many applications now split logic across three tiers instead of two: edge functions for fast, stateless decisions, application servers for business logic, and databases for persistence. That’s a more complex mental model than “client talks to server,” but it maps naturally onto how the underlying network already works. The CDN didn’t set out to become a compute platform. It became one because the infrastructure needed for fast content delivery turned out to be reusable for a much broader class of problems, and vendors followed the demand once developers started asking for it.