Design personalised page delivery at the edge for a global site. What can move to the edge, and what must not?

What belongs at the edge

• Geographic and locale routing, which needs no origin data and saves a full round-trip.
• Header and cookie inspection for experiments, feature flags and coarse audience segments.
• Template composition: a cached shell plus a small personalised fragment assembled close to the user.
• Redirects, rewrites and access checks that can be decided from the request alone.
• A/B assignment, where deciding at the edge avoids the flash of the default variant that client-side assignment produces.

What must not move there

• Anything needing the primary datastore. An edge function calling back to a single-region database has all the edge's constraints and none of its benefits — and it does so from hundreds of locations, multiplying connection pressure on the origin.
• Secrets with broad authority. Edge code runs in many locations with a wider attack surface; give it narrowly-scoped credentials only.
• Heavy computation, since edge runtimes have tight CPU and memory limits by design.
• Anything requiring strong consistency, because edge state is replicated and eventually consistent.

The constraint people underestimate

Edge runtimes are not Node.js. Limited APIs, no filesystem, restricted native modules, short execution budgets. A large share of the npm ecosystem does not run there, and discovering that late invalidates the plan rather than complicating it.

Making it operable

Deployment is global and fast, which is a hazard as much as a feature — a bad edge deploy affects every user everywhere within seconds. Staged rollout by percentage or by location, plus a fast rollback, matters more here than in a regional deployment.

And debugging is genuinely harder: logs are distributed, reproduction is location-dependent, and the same request behaves differently by region. Structured logging with a request identifier and the point of presence recorded is not optional.