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.
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?"