What Is Edge Computing?

A conventional cloud architecture sends data to central infrastructure, does the work there, and sends a result back. Edge computing moves some of that work closer to where the data is produced or where the answer is needed.

What is edge computing?

The traditional pattern is: a device sends data across the network to a central cloud, the cloud processes it, and the result returns to the device.

An edge-oriented architecture puts a processing step before that journey. The device sends data to something nearby — a local server, a gateway, a point of presence near the user, or the device itself — which handles what it can and passes on what it cannot.

The word "edge" covers a wide range. It can mean compute in a telecom facility, a server in a factory, or code running at a content network's nearest location to the visitor. What they share is position, not technology.

Why move processing closer?

Four reasons, in roughly the order they decide architectures:

• Latency. Some work cannot wait for a round trip. A safety system or a real-time control loop has a budget measured in milliseconds, and distance alone can exceed it.
• Bandwidth. Sending raw sensor or video data continuously is expensive. Processing locally and sending conclusions moves far less.
• Availability. If the network drops, work done locally continues. Work that depends on a central service does not.
• Data handling. Sometimes it matters where data is processed, not only where it is stored, and keeping it local is simpler than justifying its journey.

How do edge and cloud work together?

Edge computing rarely replaces cloud computing. It redistributes responsibility between them.

A common split: the edge handles immediate processing, filtering and time-critical decisions; the cloud handles centralised storage, coordination across locations, longer-horizon analysis and model training. Conclusions flow up, updates and configuration flow down.

Designing that split is the actual work. Put too much at the edge and you have many small systems to operate and update; put too little and you have paid for the hardware without the benefit.

Where does it matter?

Applications where the pattern pays off include computer vision, industrial monitoring, connected devices, real-time systems, local analytics and distributed applications serving users in many regions.

In each case the decision follows from concrete requirements — the latency budget, the available connectivity, how much compute the local hardware has, and what the data obligations are — rather than from the architecture being fashionable.

What should an engineer consider?

Distributing compute distributes every operational problem with it:

• Deployment. Updating code on many devices in many places is harder than updating one service, and some of them will be offline when you try.
• Observability. You need to know what happened on a device you cannot reach.
• Consistency. When edge and cloud disagree, which is authoritative?
• Partial failure. Behaviour when the link is down, and reconciliation when it returns.
• Security. Physical access to hardware is a threat model central infrastructure does not have.
• Hardware limits. Compute, memory, power and thermal constraints are real, and the model that runs in the cloud may not fit.
• Cost. Hardware, maintenance and field support against saved bandwidth and latency.

The practical conclusion

Edge computing is fundamentally a question about placement: where should this computation happen, given what it needs to be fast enough, cheap enough and reliable enough? The answer is usually "some of it here, the rest there".

---

Related reading: software architecture, and web performance.