What genuinely belongs in an edge function, and what is the failure mode of putting too much there?

What belongs

Logic decidable from the request itself, or from a small amount of edge-replicated data: routing, rewrites, header and cookie manipulation, experiment assignment, coarse authorisation, response composition from cached fragments, and normalising requests to improve cacheability.

The common property is that the function completes without asking anything far away.

The failure mode

An edge function that calls back to a central service or database. It now runs in hundreds of locations, each adding a long round-trip to the origin, and collectively opening far more connections to the origin than a regional deployment would. The result is slower than not using the edge at all, plus a new source of origin overload.

This is the single most common way edge adoption goes wrong, and it is easy to arrive at incrementally: a function that started as pure request logic acquires one lookup, then another.

The constraints that bound the design

• Tight CPU and memory limits with short execution windows, so heavy computation is not viable.
• A restricted runtime — no filesystem, limited APIs, much of the ordinary library ecosystem unavailable.
• No strong consistency, since edge state is replicated asynchronously.
• A wider trust surface, so credentials available to edge code should be narrowly scoped.

Operating them

Deployment is global and immediate, which makes a bad release a global incident within seconds — staged rollout by percentage or geography, and a fast rollback, matter more here than in a regional service.

Debugging is genuinely harder: logs are distributed, behaviour varies by location, and reproduction depends on where the request landed. Structured logging carrying a request identifier and the serving location is a requirement, not a nicety.