What Is Edge Computing? Definition and Examples

Edge computing means processing data close to where it is created, on the device itself, on a server at the site or in a nearby network node, instead of sending everything to a distant data centre. The goal is faster responses, less data traffic and operation that keeps working when the connection to the cloud is slow or interrupted. In most real architectures, the edge and the central cloud work together.

Why the edge exists

Sending data to a central data centre and back takes time and bandwidth. For many applications that does not matter: an online shop can easily tolerate a few dozen milliseconds. For others it does:

• Latency. A machine vision system that rejects faulty parts on a conveyor belt has to decide within a tight time window. Physical distance adds delay that no software can remove; see edge vs. cloud latency for how it adds up.
• Bandwidth. High-resolution cameras or sensors with high sampling rates produce more data than is sensible to upload continuously. Processing on site and sending only results or anomalies reduces traffic dramatically.
• Autonomy. A wind farm, a ship or a remote production site must keep running when the internet connection fails.
• Data protection and sovereignty. Raw data that never leaves the site cannot leak from a central system. This can simplify compliance, though it does not replace an assessment.

The layers of the edge

“Edge” is used for several places along the path from device to cloud:

Layer	Where	Typical examples
Device edge	On the device itself	Smart camera, vehicle control unit, industrial controller
On-premises edge	Server or gateway at the site	Edge server in a factory hall, store or hospital
Network edge	Data centre of a network operator close to the user	Multi-access edge computing (MEC) in mobile networks
Regional edge	Small data centres or CDN points of presence	Content caching, edge functions, regional processing
Cloud	Large central data centres	Storage, analytics, training of AI models, management

The standards body ETSI uses the term multi-access edge computing (MEC) for compute resources inside the operator network, close to the radio access.

Typical use cases

Manufacturing

Quality inspection with cameras, condition monitoring of machines and control of mobile robots on the shop floor. Here edge servers in the plant are often combined with a reliable wireless network, sometimes a private 5G campus network.

Retail

Stores process video for shelf monitoring or queue management locally and use edge servers to keep checkout systems running even if the connection to head office drops.

Logistics and transport

Ports, warehouses and vehicles process sensor and location data on site to coordinate vehicles and forklifts in real time.

Energy and utilities

Substations and wind or solar farms analyse measurements locally, react to faults and send summaries to central control systems.

Web applications

On the internet side, CDNs and edge functions serve content and run small pieces of code at locations close to users, reducing the time to the first byte.

How edge and cloud work together

A common pattern looks like this: devices and edge servers handle time-critical decisions and pre-process data; aggregated data, events and models are synchronised with a central cloud; the cloud stores history, runs analytics, trains models and distributes software updates back to the edge.

Many teams use the same tools at the edge as in the cloud: containers and lightweight Kubernetes distributions, so that software can be built once and rolled out to many sites. The principles are covered in what cloud-native means.

Challenges

• Fleet management. Hundreds of distributed sites need remote updates, monitoring and secure access.
• Physical security. Edge hardware stands in shops, halls or cabinets, not in guarded data centres.
• Limited resources. Power, cooling and space at the site constrain the hardware.
• Data consistency. Data processed locally and centrally must be reconciled.

Is edge computing right for you?

Ask three questions: Does the application need a response faster than the network path to your cloud region allows? Is the data volume too large to transfer economically? Must it keep working offline? If the answer to all three is no, a well-placed cloud region, possibly at a European provider close to your users, is usually simpler. The edge section collects further guides on latency and private networks.