advanced 1 min answer Multiple choice

A global platform is deciding what to run at the edge, in a regional cloud, and centrally. What determines the placement of each capability?

edgeplacementconsistencylatencycloudflare
Pick one
Show the full answer Hide the answer

Why latency alone is the wrong criterion

Almost everything is faster at the edge, so latency alone recommends moving everything there — which fails immediately on the first capability needing consistent state, because an edge function calling back to a single-region database has all of the edge's constraints and none of its benefits, from hundreds of locations at once.

The three questions that actually decide it

  1. What data does it need, and where does that data live? Computation belongs near the data it reads. Work requiring the primary datastore stays where the datastore is, regardless of how much latency the edge would save.
  2. What consistency does it require? Edge state is replicated and eventually consistent. Anything needing read-your-writes or a uniqueness guarantee cannot be decided at the edge alone.
  3. How much does proximity actually help? For a page load dominated by a slow origin query, moving the routing decision to the edge saves little.

The resulting placement

  • Edge: request-decidable logic — routing, redirects, header inspection, experiment assignment, cached content assembly, coarse access checks.
  • Regional: stateful services whose data is regional, latency-sensitive processing over regional data, and anything with data residency constraints.
  • Central: strongly-consistent state, analytics over the whole dataset, coordination and control planes.

The constraint teams discover late

Edge runtimes are not general-purpose runtimes. Restricted APIs, no filesystem, tight CPU and memory budgets, short execution windows. A large share of the ordinary library ecosystem does not run there — and finding that out after the design is agreed invalidates the plan rather than complicating it.

Global deployment is also a hazard: a bad edge release reaches every user everywhere in seconds, so staged rollout and fast rollback matter more here than in a regional deployment.