A client wanted edge computing. Their application felt slow to users in Southeast Asia, and someone in a meeting had mentioned edge as the answer. We measured before building anything: of the 2.3 seconds a page took to become usable, network latency to the origin accounted for about 180 milliseconds. The rest was an unindexed query, four sequential API calls that could have been one, and 1.8MB of JavaScript.
Moving compute closer to the user would have improved the 180ms. It would have done nothing about the other two seconds, and it would have made the architecture considerably harder to reason about.
This is the pattern with edge computing. It is a real technique that solves a real problem, and it is frequently proposed for problems it does not touch. Here is how to tell the difference.
Start With a Latency Budget
The only honest way to have this conversation is with numbers. Write down where the time actually goes for a real user request.
Physics sets a floor you cannot argue with: light in fibre travels roughly 200 kilometres per millisecond, and real routes are not straight. Lahore to a European data centre is around 120 to 160 milliseconds round trip on a good day. Within a city, single digits.
So the question becomes arithmetic. If your request takes 900ms and 140ms of that is the round trip, edge computing is competing for 15% of the total while you have larger, easier problems. If your total budget is 50ms and 40 of it is network, edge is the only lever that exists.
The applications with genuinely tight budgets are specific: industrial control, real-time video analysis, augmented reality, autonomous systems, competitive gaming, high-frequency trading. Most web applications are not on that list, and the honest answer for most of them is to fix the database query first.
What "Edge" Actually Means in Practice
The word covers several different things and conflating them causes most of the confusion.
CDN edge — cached static content in hundreds of locations. This is decades old and is not what people mean now, though it remains the highest return on effort for most sites.
Edge functions — small pieces of code running at CDN locations. Excellent for anything that decides quickly and does not need your database: authentication checks, A/B assignment, redirects, header manipulation, geo-based routing, personalising a cached page.
Regional compute — your actual application deployed in several regions rather than one. Not exotic, and it is what most companies asking for edge actually need.
On-premise or device edge — compute physically at the site: a machine on a factory floor, a gateway in a building, a model on a camera. This is where the most interesting engineering is, and where the hard problems live.
The Constraint That Ruins Naive Edge Designs
Here is the trap. You move your API to fifty locations. Your database is still in one. Every request now travels from the user to a nearby edge node, then across the world to the database, then back. You have added a hop and improved nothing.
Compute is easy to distribute. State is not. That sentence is the whole discipline.
The patterns that actually work all deal with state honestly:
Read replicas near the compute, accepting replication lag and designing the product to tolerate it. Fine for a product catalogue, dangerous for a bank balance.
Edge for stateless decisions only. Verify a token, choose a variant, rewrite a URL, block a bot. No database access at all.
Write locally, reconcile centrally. The edge accepts and queues, the centre becomes consistent eventually. Requires the application to genuinely handle conflicts rather than pretend they will not happen.
Partition by geography. European users' data lives in Europe and is authoritative there. Clean, and it works when users do not move between partitions — which is also how a lot of data residency compliance gets satisfied.
If a proposed edge design does not have an answer for where the writes go and what happens when two locations disagree, it is not finished.
Where 5G Fits, Honestly
5G marketing has been ahead of 5G reality for years, so it is worth separating the parts.
What is genuinely delivered: much higher bandwidth, and much higher device density — a stadium or a factory floor where thousands of connections coexist. Both matter.
The ultra-low latency figures, though, describe the radio link. Your total latency is radio plus backhaul plus internet plus your application. A one-millisecond radio hop into a network that takes ninety milliseconds to reach your server is a one-millisecond radio hop. This is exactly why 5G and edge computing are always discussed together: the low-latency promise only materialises if the compute is also close, which for most deployments means a private network or an operator's edge zone rather than the public internet.
Where it is real today: private 5G on industrial sites, replacing awkward cabling and unreliable wifi in environments with metal, movement and interference. Warehouses, ports, mines, large manufacturing floors. That is a solid, unglamorous use case with a clear return, and it is where I would look before anything consumer-facing.
Edge AI: The Clearest Case
If there is one application where moving compute to the edge is obviously correct, it is inference on high-volume sensor data.
A camera producing a video stream generates far more data than any decision it informs. Streaming it to the cloud to be told "no defect" is expensive in bandwidth, slow, and useless the moment the connection drops. Running a model locally and sending only the events is better on every axis — cost, latency, privacy and resilience.
The hard parts are not the model. They are the operations. You now have models deployed across hardware you cannot easily reach, which means you need versioning, signed updates, staged rollout and a way to know which device is running which version. You need to handle the fact that model behaviour varies with the hardware it runs on after quantisation. And you need a plan for collecting the cases the model got wrong so it can improve — which means selectively sending data back, which reintroduces the connectivity question.
The sensible split, again: local inference for the immediate decision, cloud for the model that needs the whole fleet's context, and a signed channel to push updated models back down.
The Order I Would Work In
Measure where the time goes, with real users on real connections, before choosing anything. Fix the application problems first — queries, request waterfalls, payload size — because they are usually larger and always cheaper to fix.
Then put static content on a CDN, which is the highest-value distribution step and almost free. Then move the stateless decisions to edge functions if they are on the critical path. Then, if latency is still the constraint, add regional compute with replicas and accept the consistency work that comes with it.
Reach for genuine edge computing when the physics require it: when the data is too large to move, when the decision must survive a lost connection, or when the budget is tens of milliseconds rather than hundreds.
My client's 180 milliseconds were not the problem. The unindexed query was. Distributed systems are a fine tool and a poor substitute for measuring first.
