Data Proximity

Edge computing places execution close to users, typically in tens of milliseconds of most of them. The intuitive conclusion is that moving work to the edge reduces latency.

It reduces the latency of the user-facing leg and increases the latency of the data-fetching leg. An edge function 20 ms from the user that must query a database 150 ms away completes in roughly 170 ms; an origin function co-located with that database completes in roughly 160 ms — and the edge version has added a hop, a deployment surface and a debugging problem in exchange for being slower.

Data proximity is the constraint that decides where compute belongs, and it points in the opposite direction from the intuition.

Why it matters

The computations people most want to put at the edge are personalisation ones, and those are precisely the ones that need central data. The result is a widespread architecture that is slower than the origin version it replaced, harder to debug, and adopted because the mechanism sounded like a latency optimisation.

The principle generalises well beyond the web tier. It is the same reasoning as data gravity in analytics — processing belongs where the data is, and moving data to compute is what costs — and the same reasoning behind content pre-positioning: when a fetch cannot be avoided, move it off the critical path rather than moving the compute closer.

Implementation patterns

• Compute the decision centrally and replicate the answer to the edge, so the edge reads a small widely-distributed value rather than making a round trip. This is the pattern that makes edge personalisation viable: the segment is computed at origin, the assignment is available everywhere, and the decision is local.
• Keep at the edge only what is computable from the request plus that replicated configuration: routing, bucket assignment, self-contained token validation, bot detection, header manipulation, geo-restriction.
• Cache user data at the edge with a short TTL for the classes where staleness is harmless, accepting an explicit consistency cost.
• Render the shell at the edge and stream personalised fragments from the origin, so the first paint is immediate and personalisation does not block it.
• Consider moving the origin instead. Placing the data closer to users is frequently the better answer, and it is the option skipped because it is less fashionable.
• Measure both legs, since the total is what matters and the edge leg is the one that gets reported.

Industry example

Edge function platforms — Vercel's among the most documented — expose this tension directly, and the guidance that emerged with them is consistent: edge middleware for routing, authentication and experiment assignment; origin or regional functions for anything reading a database. The platform capability that resolves the personalisation case is precomputation pushed outward rather than lookups pulled inward.

The same shape appears in the fluid-compute direction of travel — reusing warm instances and reducing cold starts — which addresses the other edge cost, and does nothing about distance to data, because nothing can.

Failure scenarios

• Edge functions performing database reads, which is slower than the origin equivalent.
• Personalisation at the edge requiring central user history, the canonical case.
• Strong consistency assumed at the edge, where replication lag makes it a correctness problem rather than a performance one.
• Large dependencies at the edge, where bundle size directly drives cold start.
• Debugging cost unaccounted for: logs across hundreds of locations, region-specific failures, and harder reproduction, paid on every incident.
• A bad edge configuration preventing a location from reaching the control plane, which cannot be fixed remotely — the reason local revert to last-known-good is essential.
• Only the edge leg measured, so the architecture appears fast while the user experience is worse.

Trade-offs

Precomputing and replicating decisions to the edge costs freshness and storage: the replicated value is stale by the propagation interval, and every edge location holds a copy. For personalisation that is usually acceptable; for entitlements, pricing or availability it may not be.

Edge execution also buys real things where the constraint holds: rejecting unauthenticated and automated traffic before it reaches the origin is a genuine capacity and security benefit, and routing decisions made locally save a full round trip.

The trade is freshness and operational complexity against latency for request-computable work only. The discipline is simply to ask, for each computation, what it needs to read — and to accept that the honest answer frequently moves the work back to the origin, which is a less exciting conclusion and a faster system.

Interview question

"We want to personalise the homepage at the edge using the user's purchase history. Walk me through the latency of that request, tell me whether it beats doing it at the origin, and then tell me how you would actually make edge personalisation work."