What Is Edge Computing? Processing Data Closer to Users

Edge computing is the practice of running computation and storing data physically close to where it’s generated or consumed, rather than routing everything back to a centralized data center. Instead of a single origin handling every request from every corner of the globe, work is pushed out to many smaller locations — “the edge” — that sit nearer to users, sensors, or devices. The payoff is lower latency, less strain on backbone bandwidth, and systems that keep working even when the connection to a central hub is unreliable.

Centralized vs edge architecture

Traditional cloud computing centralizes everything: a handful of large regional data centers run your application, and every request — no matter where it originates — travels there and back. That’s fine for a lot of workloads, but the round trip adds up. A user in São Paulo hitting a server in Virginia pays for that distance on every request, and DNS resolution and TLS handshakes only add more hops.

Edge computing distributes that work across many smaller points of presence closer to the request’s origin. It’s the same principle behind a CDN, extended from just caching static files to actually running code. Platforms like Cloudflare Workers, Fastly Compute, and similar edge-runtime products let you deploy application logic — not just cached assets — to hundreds of locations worldwide, so a request is handled by whichever node is geographically nearest.

Why the distance matters

Network latency is bounded by the speed of light, and that’s a hard physical limit no amount of engineering removes. A round trip across a continent takes tens of milliseconds no matter how fast your server responds. For a single page load that might be tolerable; for an interactive application making many sequential requests, or a real-time system like multiplayer gaming or live collaboration, those milliseconds compound into a noticeably sluggish experience.

Edge computing attacks this directly by shortening the physical distance a request has to travel. It matters most for:

• Latency-sensitive APIs — authentication checks, feature flag lookups, or personalization logic that runs on every request benefits enormously from running near the user instead of a single distant region.
• IoT and sensor data — devices generating a constant stream of readings (industrial sensors, cameras, vehicles) often can’t afford to ship every byte to a central cloud. Processing or filtering at a local edge node reduces bandwidth and lets systems react in real time.
• Content personalization — running logic at the edge to rewrite a response (A/B tests, geolocation-based redirects, auth checks) before it even reaches the origin, which is a common pattern when you deploy an Astro site to Cloudflare Pages.

Edge computing vs traditional cloud

	Centralized cloud	Edge computing
Compute location	Few large regions	Many distributed points of presence
Latency for distant users	Higher, bound by round-trip distance	Lower, request handled nearby
Bandwidth to origin	Every request travels back	Only cache misses or origin-bound requests do
Offline resilience	Central outage affects everyone	Local nodes can keep functioning
Best for	Heavy stateful processing, complex queries	Latency-sensitive, high-volume, geographically spread requests

The two aren’t mutually exclusive — most real systems use both. A typical architecture keeps a central origin for the source of truth (a database, the bulk of business logic) and pushes latency-sensitive pieces — auth checks, caching, request routing, light transformation — out to the edge. Edge runtimes are usually a poor fit for heavy, stateful computation; they’re built for short-lived, fast-executing logic close to the request.

Constraints of the edge

Edge environments trade flexibility for speed. Because a single deployment might run in hundreds of physical locations simultaneously, edge runtimes typically:

• Limit execution time and memory far more aggressively than a traditional server or container, since each node has to serve many tenants.
• Restrict the runtime to a lightweight JavaScript/WebAssembly sandbox (like a V8 isolate) rather than a full OS process, which starts far faster than a container but can’t run arbitrary binaries.
• Push developers toward eventually-consistent data — an edge node caching or storing data locally means that data may briefly diverge from the origin, similar in spirit to the trade-offs described by the CAP theorem.

This is why edge functions tend to be small, fast, stateless pieces of logic — request routing, auth token validation, header rewriting — rather than a full application server. Heavier work still belongs behind a proper load balancer and origin infrastructure.

Edge computing and databases

Storing state at the edge is the harder half of the problem. A handful of approaches have emerged: replicate a lightweight database to every edge location and accept eventual consistency, keep a single source of truth and use the edge purely for caching and compute, or use a purpose-built edge database that’s designed for this replication pattern from the ground up. Which one fits depends entirely on how much staleness your application can tolerate — a product catalog can tolerate a few seconds of lag; a bank balance generally cannot.

The takeaway

Edge computing pushes computation and data closer to where they’re needed, trading the flexibility of a centralized data center for lower latency, less backbone bandwidth, and better resilience to a single region going down. It’s not a replacement for your core infrastructure — it’s a layer in front of it, best suited to short-lived, latency-sensitive logic like auth, routing, and personalization, while your origin still owns the heavy lifting and the source of truth.