Edge Computing and the Architecture of the Next Web

For most of the web's history, the architecture was simple in concept: a user's browser sends a request across the internet to a server in a data center, the server processes it, and the response travels back. CDNs added a caching layer closer to users for static assets, but the dynamic computation — the database queries, the business logic, the personalization — happened in the origin data center.

Edge computing moves that dynamic computation out of the data center and onto servers distributed globally, positioned physically close to the users they serve. Your function does not run in us-east-1. It runs in the network node closest to the user making the request — Tokyo for a user in Japan, Frankfurt for a user in Germany, São Paulo for a user in Brazil.

The latency improvement is dramatic. A request that previously traveled 200ms round-trip to a distant origin server now resolves in 20ms from a nearby edge node. For performance-sensitive applications, this is transformative. It is also architecturally different from anything most web developers have built before, and the differences create tradeoffs that are not obvious until you hit them.

What the Edge Actually Is

"The edge" is not a single thing. It is a spectrum of compute locations between the user's device and the origin data center.

CDN edge nodes are the most numerous and the most distributed. Major CDN providers operate thousands of points of presence globally. Edge functions running here have the lowest latency and the widest geographic coverage. They also have the most constraints — limited execution time, limited memory, limited access to backend resources.

Regional edge servers are fewer in number but more capable. They run in a handful of major metro areas and support longer execution times, more memory, and persistent connections to databases and APIs. Latency is higher than CDN-level edge but lower than a centralized origin.

The origin is your traditional data center or cloud region. Full compute capability, full database access, no execution constraints. Highest latency for distant users.

The architectural decision is not "edge or origin." It is "which computation runs where on this spectrum." And the answer is different for every request, every data type, and every feature.

What Runs Well at the Edge

Edge compute excels at workloads that are latency-sensitive, stateless, and read-heavy.

Authentication and authorization. Validating a JWT or checking a session token does not require a database call. It requires parsing the token, verifying its signature, and checking its expiration. This can run at the edge in single-digit milliseconds, protecting origin servers from unauthenticated traffic and giving users immediate feedback.

A/B testing and feature flags. Evaluating which variant to show a user based on a set of rules and user attributes is a computation that benefits enormously from edge placement. The decision is made before the request reaches the origin, enabling dynamic routing without adding latency.

Content personalization. Modifying a cached page based on user attributes — locale, subscription tier, geographic region — transforms a static cache hit into a personalized response without a round trip to the origin. The edge function reads the page from cache, applies the personalization, and returns the result.

API routing and rate limiting. Rejecting abusive traffic, enforcing rate limits, and routing requests to the appropriate backend are all operations that are more effective when performed close to the requester. Malicious traffic is blocked before it consumes origin resources.

What Does Not Run Well at the Edge

Edge compute has constraints that make certain workloads impractical or impossible.

Anything that needs a database. Edge nodes are geographically distributed. Your database is not. An edge function in Tokyo that queries a database in Virginia adds the same cross-continent latency it was supposed to eliminate — except now the latency is between the edge and the database instead of between the user and the origin. The computation is at the edge, but the data round trip negates the benefit.

Distributed databases (CockroachDB, Turso, PlanetScale with read replicas) partially address this by placing read replicas near edge nodes. But writes still need to propagate, and the consistency model introduces complexity that does not exist with a single-region database.

Long-running computation. Edge functions are designed for fast responses — typically constrained to 10-50ms execution time on CDN-level edges. A report that takes 30 seconds to generate does not belong at the edge. It belongs at the origin, with the result cached at the edge.

Stateful workflows. Edge nodes are stateless by design. A workflow that requires session state, transaction state, or in-memory caching across requests cannot rely on a single edge node, because the next request from the same user may hit a different node. State must be externalized — to a distributed store, a cookie, or the origin.

The Data Gravity Problem

The fundamental tension in edge architecture is data gravity: computation moves easily, data does not. You can deploy a function to 200 edge locations in minutes. You cannot deploy a database to 200 locations at all.

This means the architecture must be designed around data location. Computation that reads globally distributed cached data works at the edge. Computation that reads from a centralized database works at the origin. Computation that needs both requires a split architecture — some work at the edge, some at the origin, with a well-defined boundary between them.

The worst outcome is an edge function that makes multiple synchronous calls to the origin for every request. This adds the overhead of the edge layer (serialization, routing, function invocation) without the benefit (reduced latency), and the result is slower than a direct origin request.

Designing for the edge means designing for data locality first and compute placement second. Ask "where is the data this function needs?" before asking "where should this function run?"

The Operational Complexity

Edge computing multiplies operational complexity in ways that are not obvious until production.

Debugging distributed edge functions is harder than debugging origin functions. Your function runs in 200 locations. A bug that manifests in only one region — due to region-specific cache state, network conditions, or timing — requires correlating logs from that specific edge node. Without strong observability tooling, this is searching for a needle in a globally distributed haystack.

Deployments are propagation events. When you deploy a new version, it propagates to all edge nodes — but not instantaneously. For a brief window, some users hit the new version and some hit the old one. If the new version changes the response format, clients may receive inconsistent responses during the rollout.

Cache coherence across edge nodes is not guaranteed. Each edge node has its own cache. A cache purge propagates, but with latency. A user whose request hits Node A sees the new content. A user whose request hits Node B, where the purge hasn't arrived yet, sees the old content. For most applications, this is acceptable. For some, it is a correctness problem.

The Takeaway

Edge computing is not a replacement for origin architecture. It is a layer that solves specific problems — latency-sensitive routing, authentication, personalization, static content delivery — extremely well. It is poorly suited for data-intensive computation, long-running processes, and anything that requires strong consistency with a centralized data store.

The architecture of the next web is not "everything at the edge." It is a spectrum — edge for the fast, stateless, read-heavy operations that benefit from proximity to users, and origin for the data-intensive, stateful operations that benefit from proximity to the database.

Design for data gravity. Put compute where the data is. And treat the edge as a performance and resilience layer, not as a replacement for the backend.

---

Next in the "Web Platform at Scale" learning path: We'll cover observability for web applications — distributed tracing, real user monitoring, and the instrumentation that tells you what your application is actually doing in production versus what your tests said it would do.