A frontend platform runs functions at the edge for personalisation but must read user data that lives in one region. Which computations genuinely belong at the edge, and when does "edge" make debugging and consistency worse?

The arithmetic that decides it

The edge is close to the user and far from the data. An edge function 20 ms from the user that must call a database 150 ms away has produced a 170 ms round trip where an origin function co-located with the data would have produced 160 ms — and it has added a hop, a deployment target and a debugging surface for nothing.

The edge wins only when the computation does not need origin data, or when it needs so little that the saving on the user-facing leg exceeds the cost of the origin leg.

What genuinely belongs at the edge

• Routing and rewriting decisions based on the request itself: geography, device, language, path.
• A/B test bucket assignment from a cookie or a deterministic hash, requiring no lookup.
• Authentication token validation, where the token is self-contained and verification is cryptographic — which lets an unauthenticated request be rejected without ever reaching the origin.
• Bot detection and rate limiting, best done as close to the source as possible.
• Header and cookie manipulation.
• Serving cached content with light per-request variation, where the expensive part is already cached.
• Redirects and geo-restriction.

The common property: the decision is computable from the request plus a small, widely-replicated configuration set.

What does not belong at the edge

• Anything requiring a database read, unless the data is genuinely replicated to the edge.
• Personalisation requiring user history or preferences from a central store — the canonical mistake, because it is the case people most want to put at the edge and the one where the data is furthest away.
• Anything requiring strong consistency, since edge replicas are eventually consistent and the staleness is a correctness question rather than a performance one.
• Heavy computation, given edge runtime constraints on CPU, memory and duration.
• Anything needing a large dependency, since bundle size directly affects cold start at the edge.

The resolutions that actually work

• Precompute at the origin and push to the edge, so the edge reads a replicated value rather than making a round trip. This is the pattern that makes edge personalisation viable: the segment is computed centrally, the assignment is available at the edge, and the decision is local.
• Cache the user's data at the edge with a short TTL, accepting staleness for the classes of data where it is harmless.
• Render the shell at the edge and stream personalised fragments from the origin, so the user sees something immediately and personalisation arrives without blocking.
• Move the origin closer to the users, which is frequently a better answer than moving the compute — and is the option people skip because "edge" is the fashionable one.

Where edge makes things worse

• Debugging. Logs and traces from hundreds of locations, an error affecting one region only, and behaviour that varies by point of presence. Reproduction is genuinely harder, and this cost is paid on every incident.
• Consistency. Configuration and data propagate to edge locations with a lag, so different users see different behaviour during a rollout — which is a correctness problem when the variation affects pricing, entitlements or availability.
• Rollback. A configuration that must reach hundreds of locations to be reverted is slower to fix than one in a single deployment — and a bad edge configuration that prevents a location from reaching the control plane cannot be fixed remotely at all, which is why local revert to last known good matters.
• Cost model. Per-invocation pricing across many locations behaves differently from a fixed origin fleet, and the crossover is worth computing before committing.

The honest framing: the edge is a latency optimisation for computations that do not need central data, and applying it to computations that do produces a slower, harder-to-debug system with a better story.