Edge Computing: What Moving Compute Closer Actually Buys You

Edge computing is the practice of running code in a few hundred small locations instead of a few large ones. The pitch is physics: light in glass is slow enough that distance costs measurable milliseconds, and no amount of engineering removes them. The pitch is also, quite often, oversold — because most of what makes an application feel slow has nothing to do with the distance to the server.

The physics, and exactly how much it buys

Light travels at 299,792 kilometres per second in vacuum. In the silica core of a single-mode fibre it is slowed by the refractive index of the glass, roughly 1.47, which puts the signal at about 204,000 kilometres per second — a little over two-thirds of the vacuum figure.

Convert that into the unit that matters. One thousand kilometres of fibre costs about 4.9 milliseconds one way, so a round trip over that distance costs about 10 milliseconds, and there is no technology that will reduce it. A few consequences, using straight-line distances:

• Toronto to Vancouver is roughly 3,350 km, so the floor is about 16 ms one way and 33 ms for a round trip.
• Toronto to London is roughly 5,700 km — about 28 ms one way, 56 ms round trip.
• Toronto to Sydney is roughly 15,500 km — about 76 ms one way, 152 ms round trip.

Those are floors, not measurements. Real fibre does not follow great circles; it follows rights of way, sea beds and existing duct. It passes through amplifiers, switches and routers, each adding its own small delay. In practice measured round trips run comfortably above the theoretical minimum, often by a third or more.

Now notice what this means for protocols. A TLS handshake and a TCP connection cost round trips before any content moves. On a 150 ms path, three round trips of setup is nearly half a second the user experiences as nothing happening. Moving the termination point 6,000 km closer does not make the content arrive faster — it makes the negotiation finish faster, several times over.

What actually needs the edge

The honest test is whether the work can be completed without consulting a central source of truth. If it can, the edge is a straightforward win. If it cannot, moving the code to the edge just moves the queue.

Genuinely well suited:

• Connection termination. TLS handshakes, HTTP/3 setup, and header manipulation — all of it is stateless and all of it is round-trip bound.
• Routing and rewriting decisions. Redirects, A/B assignment, locale selection, path rewrites, adding security headers, blocking a bad user agent.
• Cache logic. Normalising cache keys, stitching a personalised fragment into an otherwise cacheable page, serving stale content while revalidating.
• Bot and abuse filtering. Rejecting junk near its origin is cheaper than hauling it to a data centre first.
• Image and asset transformation. Resize and re-encode once at the edge, cache the result.

Poorly suited, whatever the marketing says:

• Anything that reads a single authoritative database. If your edge function in Halifax must query a database in Virginia, you have added a hop, not removed one.
• Anything requiring strong consistency across regions. Distributed consensus costs round trips between replicas, and those round trips obey the same physics.
• Long or memory-hungry computation. Edge runtimes are deliberately constrained; heavy jobs belong where the hardware is.
• Anything whose real cost is elsewhere. If a page takes 2.4 seconds because it ships four megabytes of JavaScript, shaving 40 ms off the first byte is not the fix.

Edge functions as a category

The commercial form of edge computing is the small, short-lived function that runs in every PoP. The interesting engineering is in how the isolation is done, because a container per customer per location does not scale to hundreds of sites.

Cloudflare’s Workers use V8 isolates — the same sandboxing JavaScript engines use to separate browser tabs — rather than a process or a virtual machine per tenant. Cloudflare’s documentation states that a single runtime instance can run hundreds or thousands of isolates, that an isolate starts around a hundred times faster than a Node process in a container or VM, and that isolates consume an order of magnitude less memory at startup. That is what makes “run this everywhere” affordable.

The constraints follow directly from the model. Cloudflare’s published limits give each isolate 128 MB of memory, cap free-plan CPU time at 10 milliseconds per request, and note that a typical Worker uses around 2.2 ms of CPU while authentication or server-side rendering workloads run 10 to 20 ms. The same documentation warns against storing mutable state in the global scope, because isolates can be evicted at any time. This is a platform for short, stateless work, and it is honest about it.

MEC: the edge inside the mobile network

The telecoms industry arrived at the same idea from a different direction. ETSI launched an Industry Specification Group in late 2014 under the name Mobile Edge Computing, and renamed it Multi-access Edge Computing during its second phase, once the scope widened beyond cellular to other access technologies. The group is now working through a fourth phase.

The concept, in ETSI’s own leaflet, is cloud computing capability and an IT service environment at the edge of the mobile network, with real-time access to radio network information — that last part being the piece a general-purpose CDN cannot offer. The IEEE Future Networks overview describes MEC as an enabler for ultra-low-latency requirements in areas such as automotive, healthcare and public safety.

Worth reading carefully: those documents are consistently qualitative about latency. They say “ultra-low” rather than a number, because the number depends on where the compute sits relative to the radio, which varies by deployment. Be sceptical of any vendor claim that attaches a specific millisecond figure to MEC in general.

The trade-offs nobody puts on the slide

State is the whole problem. The moment your edge function needs to remember something, you are choosing between reading from a central store (which reintroduces the latency you were removing), replicating everywhere (which costs consistency), or accepting per-location state (which means two users get different answers). Every serious edge platform now sells a storage product, and every one of those products makes a specific consistency compromise you have to understand.

Debugging gets harder in a specific way. A bug that only manifests in one PoP, under one carrier’s routing, at one time of day, is genuinely difficult to reproduce. Logs are distributed; you cannot attach a debugger to the machine in question.

Deployment risk goes up, not down. Code that reaches every location in under a minute is the same property that lets a bad configuration reach every location in under a minute. The major CDN outages of the last several years have almost all been configuration or code pushes rather than hardware faults.

The pricing model is different. Edge platforms bill per request and per unit of CPU time rather than per hour of a reserved machine. That is excellent for spiky, cheap work and unpleasant for steady, expensive work. Run the arithmetic on your actual request volume before assuming it is cheaper.

Data residency cuts both ways. “Runs in hundreds of countries” is a compliance question as well as a performance feature, and for Canadian organisations handling personal information it is a question worth answering before deployment rather than after.

The practical version

• Do the subtraction first. Measure your current time to first byte, then estimate how much of it is propagation delay using roughly 10 ms per 1,000 km of round trip. If propagation is 30 ms of a 900 ms response, the edge is not your problem.
• Move the handshake before you move the logic. Simply putting a CDN in front of an origin captures most of the round-trip win with none of the state problems.
• Only run code at the edge if it can answer without asking anyone. That is the whole test.
• Design for eviction. Edge runtimes discard isolates whenever they like; anything you cached in a global variable is a performance optimisation, never a source of truth.
• Treat an edge deploy like a global deploy, because it is one. Stage it, ramp it, and keep a fast rollback.