Edge Computing

The "edge" is the edge of the network: the point closest to where data is created or consumed. A traditional cloud setup might process all your requests in one region, say AWS us-east-1 in Virginia. If your user is in Mumbai, every request makes a round trip of roughly 12,000 km, which adds 200 ms or more just in network travel before any work happens.

Edge computing moves the work outward. Instead of one big data center, you run smaller compute nodes in hundreds of locations: ISP facilities, telecom towers, retail stores, factory floors, or content delivery network points of presence. The request is handled by the nearest node, so the round trip might be 50 km instead of 12,000 km.

It sits on a spectrum. A CDN edge cache that only serves static files is the lightest form. Running actual application logic, like authentication or image resizing at the edge, is heavier. Putting a full server rack in a factory to process sensor data on-site is the heaviest, often called on-premise or fog computing.

A request first hits DNS or anycast routing, which points the user at the nearest edge location instead of the origin. Anycast is common: the same IP address is announced from many sites, and internet routing naturally sends each user to the closest one.

At the edge node, a lightweight runtime executes your code. Cloudflare Workers and AWS Lambda@Edge use V8 isolates or small containers that cold-start in under 5 ms, far faster than a full virtual machine, because you cannot afford slow startups when you have thousands of small nodes.

State is the hard part. Edge nodes usually keep a cache and a small replicated database for reads, while writes and the source of truth still flow back to a central region. Systems like Cloudflare's D1, Fly.io's read replicas, or DynamoDB Global Tables push data out to the edge so most reads are local and only a fraction need the full trip home.

Reach for edge computing when latency is the product: live video, multiplayer games, AR/VR, autonomous vehicles, payment authorization, and IoT control loops where a 200 ms delay is unacceptable. It also helps with bandwidth, since processing a video feed on-site means you ship a small result instead of the raw stream, and with data residency, since you can keep data inside a country by processing it locally.

The cost is complexity. You now operate hundreds of locations instead of one, so deployment, monitoring, and debugging get harder. Edge runtimes are restricted: limited memory, short execution time, no full file system, and often a subset of language features. You cannot just lift and shift a heavy backend there.

Consistency is the real tax. Data spread across many nodes means you accept eventual consistency for most reads, and you have to decide what must be strongly consistent and route those operations back to the core. Anything stateful and write-heavy is usually a poor fit for the edge.

Picture a global e-commerce site. A shopper in Tokyo loads a product page. The HTML shell, images, and JavaScript are served from a CDN edge node in Tokyo in about 10 ms. An edge function checks their auth cookie and runs an A/B test assignment right there, no trip to Virginia needed.

When they add an item to the cart, that write goes back to the central database because inventory and orders need a single source of truth. But the price display, currency conversion, and personalized recommendations are computed at the edge from replicated data.

The result: the page feels instant everywhere in the world, the origin handles far fewer requests because the edge absorbs the read-heavy traffic, and the central database only sees the small slice of operations that genuinely need it.