The Edge Won, and Nobody Threw a Party

A few years ago, running code at the edge was a talking point. Today it is a checkbox on every major platform, and the marketing has moved on. That is usually the sign that a technology has actually been adopted: it stops being sold and starts being assumed.

The easy win is mostly spent

Serving static assets and cached HTML from a nearby location is a solved problem, and the gains have been collected. Most applications that feel slow today are not waiting on the network path to the origin. They are waiting on a database query in a single region, or on four sequential API calls that could have been one, or on three hundred kilobytes of JavaScript that must parse before anything is interactive.

Moving the compute closer without moving the data closer just relocates the round trip. A function running twenty milliseconds from the user that then makes three calls to a database eight thousand kilometres away is slower than a monolith sitting next to that database.

Data gravity is the real constraint

This is why the interesting work has shifted to the data layer: read replicas placed near traffic, edge-resident caches with sane invalidation, and databases designed to be reached from anywhere without paying for a cross-continent hop per query. The design question is no longer where does my code run. It is which reads can tolerate being slightly stale, and how do I know when they cannot.

• Session and preference data tolerate staleness of seconds and belong close to the user.
• Content and catalogue data tolerate staleness of minutes and belong in a cache with an explicit invalidation path.
• Balances, inventory, and anything a user can dispute tolerate nothing and belong on a single authoritative path, wherever that is.

Most performance disasters come from misclassifying the third bucket as the second.

The operational cost is real

Distributed execution means distributed failure. A function that runs in thirty locations fails in thirty locations independently, and your logs arrive from all of them with clock skew. Debugging requires trace propagation and a log store that can reassemble a single user's journey across regions. Teams that adopted the edge for latency and skipped this work discovered it during their first partial outage.

Every architecture that improves the median makes the tail harder to explain. Budget for the explaining.

What actually deserves the runtime

Authentication checks, redirects, geo-based routing, personalisation of otherwise cacheable pages, and request rewriting all benefit enormously from running before the request travels anywhere. That is a modest, valuable list, and it is where the technology earns its place.

The rest of your application probably belongs in a boring regional deployment next to its database, and admitting that is not a failure of ambition. It is what a mature default looks like.