Design systems that push computation to the network edge for lower latency, reduced bandwidth, and real-time processing. Covers edge vs cloud trade-offs, CDN workers, IoT edge, edge databases, and the patterns that make edge computing practical.
Edge Computing Architecture is the design and operational model for deploying compute, storage, and networking resources closer to data sources and end users. It matters when latency, bandwidth, or real-time processing are critical—such as in industrial IoT, autonomous vehicles, real-time video analytics, or mobile-first applications with high user interaction.
To place a service at the edge, you must define where the edge nodes are, how they are provisioned, and how they connect to the cloud. The edge node is typically a Linux machine—often ARM-based—running a lightweight container runtime, with a configuration that defines its role and behavior.
The deployment process begins with a manifest, a JSON file describing the services to run, their dependencies, and their lifecycle:
{
"version": "1.0",
"services": [
{
"name": "video-analyzer",
"image": "registry.example.com/video-analyzer:2.3",
"ports": [8080],
"env": {
"MODEL_PATH": "/models/person-detection.onnx",
"MAX_FRAME_RATE": "30"
},
"resources": {
"cpu": "1000m",
"memory": "512Mi"
},
"volumeMounts": [
{
"name": "model-storage",
"mountPath": "/models"
}
]
},
{
"name": "telemetry-ingestor",
"image": "registry.example.com/telemetry-ingestor:1.1",
"command": ["/ingestor", "--source", "kafka://edge-kafka:9092"]
}
],
"volumes": [
{
"name": "model-storage",
"type": "persistent",
"path": "/var/lib/models"
}
],
"network": {
"name": "edge-lan",
"subnet": "192.168.10.0/24",
"gateway": "192.168.10.1"
}
}This manifest is distributed to edge nodes via a configuration service, often over a lightweight protocol like MQTT or HTTP. The edge node uses a daemon—such as edged, k3s, or containerd—to apply the manifest and manage the lifecycle of services.
sudo edged --config /etc/edge/manifest.json --sync
# Watch status
sudo edged status --watchThe edged daemon ensures the desired state is maintained: it pulls images, starts containers, monitors health, and reconciles changes. If a service crashes, edged restarts it and logs the failure in /var/log/edged/.
Edge nodes are often behind unreliable networks. They may start with no connectivity, experience intermittent outages, or lose the cloud entirely. The architecture must handle these conditions gracefully.
When a node boots, it fetches its manifest from a cloud-based configuration store—such as a REST API or a database—using a bootstrap script:
#!/bin/sh
# bootstrap.sh
set -e
# Fetch manifest from cloud config server
curl -s http://config.edge.example.com/v1/nodes/$(hostname)/manifest \
-H "Accept: application/json" \
-o /etc/edge/manifest.json
# Apply configuration
sudo edged --config /etc/edge/manifest.json --apply
# Start services and enable auto-reconnect
sudo systemctl enable edged
sudo systemctl start edgedThe node registers itself with the cloud via a heartbeat mechanism. Every 30 seconds, it sends a POST /heartbeat request:
POST /heartbeat HTTP/1.1
Host: cloud.edge.example.com
Content-Type: application/json
{
"nodeId": "edge-003a",
"status": "online",
"uptime": 1245,
"network": {
"interface": "eth0",
"ip": "192.168.10.15",
"ping": 12.4
},
"services": [
{
"name": "video-analyzer",
"status": "running",
"uptime": 320,
"cpu": 23.5,
"memory": "140Mi"
}
]
}If the cloud becomes unreachable, the edge node enters disconnected mode: it continues running services locally, caches state, and queues messages to be sent when connectivity resumes. The edged daemon persists a local state database in /var/lib/edged/state.db, a SQLite file that tracks service states, version history, and pending tasks.
When connectivity resumes, edged performs a reconciliation: it checks for changes in the manifest, downloads updated images, and applies them with zero downtime. It uses a two-phase update protocol:
If the update fails, the node rolls back using the previous version.
Data at the edge flows through a pipeline of ingestion, processing, and synchronization with the cloud.
Devices (e.g., sensors, cameras, mobile clients) send data to the edge node via protocols such as MQTT, CoAP, or gRPC. A typical ingestion pipeline uses a message broker—like Kafka, RabbitMQ, or NATS—running on the edge node.
# Start edge Kafka instance
sudo systemd run --user --scope \
kafka-server --config /etc/kafka/server.properties \
--data-dir /var/lib/kafka \
--advertised-host-name edge-003aA kafka-server.properties file configures the broker:
broker.id=1
listeners=PLAINTEXT://0.0.0.0:9092
advertised.listeners=PLAINTEXT://192.168.10.15:9092
log.dirs=/var/lib/kafka
default.replication.factor=2
min.insync.replicas=2Producers send events to topics like camera-frames and sensor-telemetry. Consumers—such as the video-analyzer service—subscribe and process messages:
// video-analyzer/main.go
package main
import (
"context"
"fmt"
"log"
"time"
"github.com/Shopify/sarama"
)
func main() {
config := sarama.NewConfig()
config.Consumer.Group.Return.Errors = true
config.Consumer.Offsets.Initial = sarama.OffsetNewest
client, err := sarama.NewConsumer([]string{"edge-003a:9092"}, config)
if err != nil {
log.Fatal(err)
}
defer client.Close()
partitionConsumer, err := client.ConsumePartition("camera-frames", 0, sarama.OffsetNewest)
if err != nil {
log.Fatal(err)
}
defer partitionConsumer.Close()
go func() {
for err := range partitionConsumer.Errors() {
log.Printf("Error: %v\n", err)
}
}()
for {
select {
case msg, ok := <-partitionConsumer.Messages():
if !ok {
continue
}
processFrame(msg.Value)
case <-time.After(10 * time.Second):
// Heartbeat
fmt.Printf("Processing at %s\n", time.Now().Format("15:04:05"))
}
}
}When data is ready to be sent to the cloud, the edge node uses delta synchronization. It maintains a checkpoint of the last processed message for each topic and sends only new or changed data.
For example, the telemetry-ingestor service writes data to a local SQLite database and periodically uploads it:
-- Upload only new records since last checkpoint
INSERT INTO cloud_telemetry
SELECT * FROM local_telemetry
WHERE timestamp > (SELECT last_sync FROM sync_checkpoints WHERE topic = 'sensor-telemetry');After upload, it updates the checkpoint:
UPDATE sync_checkpoints
SET last_sync = '2024-07-25T12:30:00Z'
WHERE topic = 'sensor-telemetry';If the upload fails, the service retries using exponential backoff, with jitter:
{
"retries": [
{ "attempt": 1, "delay": "1s", "status": "failed" },
{ "attempt": 2, "delay": "2s", "status": "failed" },
{ "attempt": 3, "delay": "4s", "status": "success" }
]
}The edge node can also aggregate data before sending. For instance, it computes rolling averages of sensor readings and sends only summary records, reducing bandwidth and cloud storage.
Edge computing silently fails in subtle ways. The most common failure is config drift: a node’s manifest diverges from the cloud configuration, but the difference is never noticed.
When a new service is added, the cloud sends an updated manifest, but the edge node fails to apply it due to a network timeout. The edged daemon logs a failed to apply manifest error, but the service remains in an old state.
{
"error": "failed to apply manifest",
"timestamp": "2024-07-25T12:00:00Z",
"details": {
"manifestVersion": "1.0",
"appliedVersion": "1.0",
"error": "failed to pull image: registry.example.com/video-analyzer:2.3",
"code": 408,
"message": "Request Timeout"
}
}Another silent failure occurs when time synchronization is off. Edge nodes often use NTP, but poor network conditions lead to drift. A service logs events with timestamps that differ by seconds across nodes, complicating debugging.
The system must handle node failure and recovery. When a node fails, it must be re-provisioned from scratch. The bootstrap script runs again, but if the node has no persistent storage, it loses its state. To prevent this, the edge node should mount a persistent volume from an external source—such as a USB drive, SD card, or iSCSI volume.
The most common configuration mistake is misconfigured network interfaces. The edge node has multiple interfaces—eth0, wlan0, and a cellular modem—but the default route is incorrect. A service that expects to reach the cloud via 192.168.10.1 fails because it’s configured to use 10.0.0.1.
To diagnose this, engineers use ip route show and ip addr show, and verify connectivity with ping -c 3 cloud.edge.example.com.
When multiple edge nodes sync data to the cloud, conflicts arise. For example, two nodes update a shared configuration file at the same time.
The system uses timestamp-based conflict resolution. Each update includes a lastModified timestamp and a version number. The cloud applies updates using a last-write-wins strategy:
{
"name": "camera-001",
"location": "factory-floor",
"lastModified": "2024-07-25T12:34:56Z",
"version": 12,
"settings": {
"resolution": "1080p",
"frameRate": 15
}
}If two updates arrive with different versions, the cloud accepts the one with the higher version. If versions are equal, it uses the timestamp to resolve ties.
In case of high-latency or disconnected updates, the system uses merge strategies:
When a cloud update is applied, it triggers a push notification to all edge nodes via a message queue or HTTP long polling.
An edge system must be observable even when disconnected. Each service exposes a /health endpoint:
GET /health HTTP/1.1
Host: edge-003a
HTTP/1.1 200 OK
Content-Type: application/json
{
"status": "ok",
"details": {
"services": [
{
"name": "video-analyzer",
"status": "running",
"uptime": 320,
"memory": "140Mi",
"cpu": 23.5
}
],
"network": {
"connected": true,
"ping": 12.4
}
}
}The edge node runs a health checker that periodically probes services and uploads results to the cloud.
A central dashboard collects health data, logs, metrics, and traces. It uses a pull-based model: cloud services query edge nodes for data, and edge nodes expose a /metrics endpoint in Prometheus format:
# HELP service_cpu_usage CPU usage in percent
# TYPE service_cpu_usage gauge
service_cpu_usage{service="video-analyzer"} 23.5
service_cpu_usage{service="telemetry-ingestor"} 14.2When a node becomes unhealthy, the dashboard triggers alerts via email, Slack, or a push notification.
Edge computing architecture is defined by the placement of compute resources near data sources, with resilient, self-managed nodes that operate independently. It relies on manifest-driven deployment, message-based data flow, and robust synchronization between edge and cloud. The key patterns—disconnected operation, delta updates, reconciliation, and conflict resolution—must be implemented with care. The most common failures stem from network instability, configuration drift, and time misalignment. Engineers must monitor services using standardized health checks and metrics, and design systems that recover gracefully from partial or total loss of connectivity.
This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy