Edge computing gets discussed as though every application should be moving toward it. In practice most teams asking the question already have the only version of it they need, and adding more would cost them time for no gain.
The confusion comes from three different things sharing one word.
Three things called edge
A CDN caches your static assets close to users. Images, scripts, stylesheets, cached pages. If you use one, you already have geographic distribution for the part of the payload that dominates load time. This solves most perceived-latency problems in most web applications.
Edge functions run small pieces of logic at those same points of presence. Routing, redirects, header rewriting, personalisation decisions, auth checks. Useful, genuinely fast, and constrained: short execution limits, restricted runtimes, and no local state worth relying on.
Edge computing proper means compute on hardware you or your customer controls, near where the data is produced. A gateway on a factory floor, a server in a retail branch, a box in a vehicle. This is a different discipline with different economics.
Conflating these is why the topic feels bigger than it is. Most articles about the third are read by people who need the first.
The question that settles it
Ask what breaks if the round trip to your cloud region takes 80 milliseconds instead of 5.
For an e-commerce store: nothing. Page weight and database queries dominate. The user cannot tell.
For a dashboard, an admin tool, a CMS: nothing.
For a machine safety interlock, a robot arm, a real-time control loop: everything. Which is why edge computing grew up in industrial settings rather than web ones.
If the honest answer is "nothing", the edge conversation is over and the time is better spent on query performance and image sizes.
Where it genuinely pays
Latency that has a physical consequence. Control systems, machine vision on a production line, anything where a decision must complete before something physical moves. The round trip is not a user-experience concern, it is a functional limit.
Bandwidth that would be absurd to ship. A camera producing continuous video, a sensor array sampling at high frequency. Processing locally and sending events rather than raw data is the difference between a viable system and an unaffordable one.
Data that must not leave. Regulatory or contractual constraints keeping raw data on site. Process locally, ship aggregates. This one is a requirement rather than an optimisation, and it decides the architecture on its own.
Operating through an outage. A shop whose till must keep working when the line drops. Local processing with reconciliation on reconnect — which is really an offline-first design problem, and the hard part is the reconciliation, not the placement of the compute.
What it costs
Every one of those cases is real. So are the costs, and they are the reason not to adopt it speculatively.
You now have a fleet. Deployment, monitoring, updates and failure handling on machines you cannot ssh into casually — physical devices in places without engineers.
You have state in more than one place. Which means conflicts, which means a reconciliation strategy, which is the hardest part of any distributed design.
You have a larger attack surface, distributed across sites with uneven physical security.
And you have divergence. Edge nodes drift out of version alignment, and reproducing a bug that only occurs on the ones that missed an update is genuinely unpleasant.
The pragmatic ladder
Start with a CDN. It is cheap, it is solved, and it addresses the majority of latency complaints in web applications.
Add edge functions when you have logic that must run before the origin is reached — routing, auth, geographic redirects, an A/B decision.
Move compute to physical edge hardware only when one of the four cases above applies to you specifically. Not because the architecture diagram would look more modern.
The interesting part of most infrastructure work is not distribution. It is that the query is slow, the images are unoptimised, and there is no caching layer where one belongs. Fixing those beats relocating the problem.
We do infrastructure and platform work including the unglamorous version. If you are weighing this up, we will tell you if a CDN is your answer.
