A team proposes moving personalisation to edge functions to cut latency. When does that work and when does it backfire?

The principle that decides it

The edge is near the user and far from your data. Edge compute pays off for work that needs the request but not your state. The moment a function must read or write shared data, its latency is dominated by distance to that data — and it has moved further from it, not closer.

Where it works

Anything derivable from the request itself: geolocation, device type, language, headers, cookies, A/B assignment from a hashed identifier, routing and rewrites, bot filtering, redirects, token validation using a public key.

Assembling a personalised shell around cached content — serve a cached page from the edge and inject the user-specific fragments, which keeps the expensive part cacheable while the page still looks personalised.

Auth at the edge, rejecting unauthenticated requests before they consume an origin round trip. A JWT can be validated with a cached public key and no state lookup at all.

Where it backfires

Personalisation that requires user history or a profile lookup. The edge function now calls your origin database — from a point of presence potentially further away than the user's own path to your origin — so the total is worse than doing it at the origin, plus a hop.

Anything needing strong consistency. Edge-adjacent data stores are eventually consistent and regionally replicated by design.

Complex computation. Edge runtimes have short CPU limits and small memory; work that exceeds them fails in ways that are awkward to debug.

The design I would propose

Split personalisation by data dependency. Do at the edge everything derivable from the request; do at the origin anything needing the profile — and cache the profile-derived fragment aggressively with a short TTL, since personalisation is usually stable for minutes.

Then measure. If the profile lookup dominates, the win is in caching that lookup, not in relocating the computation.

What a strong answer adds

Asking what the latency actually is now, and where it is spent. Teams frequently propose edge compute for a page whose latency is dominated by an origin database query or by third-party scripts in the browser — where moving compute to the edge changes nothing measurable. The measurement should precede the architecture.