tool

Edge Functions

Small units of code executed at points of presence near users — powerful for stateless work, constrained by the limits of the runtime and the difficulty of state.

edgeserverlesslatencystateconstraints

Definition

Code executed at distributed points of presence rather than in a region, so a request is answered a few milliseconds from the user rather than across an ocean.

What belongs there

  • Routing and rewriting — choosing an origin, normalising a URL, applying a redirect.
  • Authentication and token validation — rejecting an invalid request near the user rather than hundreds of milliseconds away.
  • Personalising cached content — assembling a cached page with a small user-specific fragment, so the expensive part stays cacheable.
  • Experiment assignment, computed from a hash of the user identifier, needing no storage at all.
  • Rate limiting and bot mitigation, far more effective near the source of traffic.
  • Image transformation and format negotiation.

The constraints

  • Short execution limits and small memory. Not a general compute environment.
  • Restricted runtimes and APIs. Many libraries will not run.
  • No local durable state. This is the fundamental one.
  • Deployment is global and fast, which is a hazard as much as a feature: a bad configuration reaches every user in seconds, so canary and rollback matter more here, not less.
  • Debugging is harder — distributed, constrained, with limited tooling.

The state problem, which is the real difficulty

Running code in hundreds of locations is straightforward. Giving it consistent data is not, and every option is a compromise:

  • Replicate globally, accepting eventual consistency.
  • Pin state to one location per object, with edges routing to it. Gives strong consistency per object and locality for the users who matter most for that object — under-used, and the best fit for carts, documents, sessions and rooms.
  • Keep state at the origin and use the edge only for stateless work. Simplest and frequently correct.

Failure scenarios

  • Business logic drifting to the edge, so critical behaviour lives in a constrained runtime with a different deployment model and limited debugging.
  • Edge state assumed consistent, producing bugs that appear only for users in certain regions.
  • A configuration change deployed globally with no canary — the blast radius is every user at once.
  • Execution limits hit by logic that grew beyond what the runtime was for.

Interview question

"Which parts of a personalised page would you compute at the edge, and where does each piece of state live?"