Computing at the edge

Edge platforms do not run ordinary servers. They run many small isolated contexts inside a shared runtime, started per request in microseconds rather than as containers, which is what makes them cheap enough to place in hundreds of locations. That model buys the startup time and imposes constraints that surprise anyone porting existing code.

The limits are real and worth knowing in advance. CPU time per request is measured in milliseconds rather than seconds. Memory is tens of megabytes. The available APIs are web standard rather than the full runtime of the language, so a library depending on the filesystem or on raw sockets may simply not work. And the process does not persist, so nothing can be kept in memory between requests as though it were a server.

Statelessness is the constraint that shapes the design. There is no local disk and no reliable in-process cache, so state lives in a platform service: a key-value store with eventual consistency, an object store, a database designed to be reachable from many locations, or a coordination primitive that pins a piece of state to one place. Each has a latency and consistency profile that has to be chosen deliberately.

Data locality then becomes the central design question, because a globally distributed compute layer over a single-region database is a distributed system with a hundred fast front ends and one slow shared dependency. The patterns that work are reading locally from replicated storage, writing to a home region, and pushing anything genuinely global through a mechanism designed for it rather than through the database by accident.

None of this makes the edge unsuitable, it makes it a specific tool. Small, fast, stateless work with a nearby state store is what it does extremely well. A long-running job, a large in-memory model, or a handler that needs a transaction against a primary is what it does badly, and knowing the boundary is more valuable than any amount of tuning on the wrong side of it.

The most valuable property of the edge is not speed, it is that hostile traffic can be refused before it reaches anything you own. A request absorbed in a location near its source never consumes origin capacity, never opens a database connection and never runs a line of your code, which is a different kind of protection from a service that handles the request efficiently.

Volumetric attacks make the argument by themselves. A distributed denial of service that would saturate an origin's link is spread across hundreds of locations, each seeing a fraction, and absorbed by capacity that exists anyway for legitimate traffic. No origin-side rate limiter helps with an attack that fills the pipe before arriving, because the damage is done upstream of anything you control.

The layer above that is deciding who is worth serving. Bot management, filtering by reputation, challenges for suspicious clients and blocking obviously malformed requests all belong here, because each is a decision needing only the request and some shared intelligence. Doing the same work at origin means paying for the connection and the compute to reject something you did not want.

Rate limiting at the edge is subtly better than at origin for a reason worth stating: the edge sees the whole picture. A limiter running on each origin instance sees only its own share of the traffic, so a limit of a hundred a minute becomes a hundred per instance, while the edge counts the caller across every location and applies the limit that was actually intended.

The mistake is treating the edge as sufficient. It is a filter, not an authorisation system, and anything reachable by a request that gets past it still needs its own checks, because a leaked origin address, an internal caller or a rule that is one release out of date will all bypass it. Defence in depth means the edge removes the volume and the origin still refuses what it should refuse.