Why architecture matters here
Architecture matters here because the edge's advantages and its constraints are two sides of the same coin, and building for it means constantly deciding which side of the edge/origin line each piece of work belongs on. Put too much at the edge and you slam into the CPU and memory budgets or need data the edge cannot consistently hold; put too little and you have paid for a global fleet that just proxies to a distant origin, capturing none of the latency win. The architecture is a placement problem, and the placement decisions are where edge compute succeeds or fails.
The headline benefit is latency, and it compounds. Serving a request from a PoP 20 milliseconds away instead of an origin 200 milliseconds away is a 10x improvement on the network leg, but the real win appears when a page or an API makes several dependent calls: each round trip that stays at the edge saves the full origin distance, so a flow that would have been several sequential transcontinental hops collapses to local ones. For anything on the critical rendering path — auth, redirects, personalization that gates the first byte — moving it to the edge can be the difference between a page that feels instant and one that visibly stalls.
The second benefit is origin offload and resilience. Every request the edge fully handles — from cache, from edge KV, from pure computation — is a request the origin never sees. This shields the origin from traffic spikes, cuts its egress and compute bill, and keeps a lot of functionality working even when the origin is slow or briefly down. A well-designed edge layer absorbs the bulk of traffic and lets the origin do only the irreducible stateful work, which is both cheaper and more robust than routing everything to the core.
But the isolate model that makes this economical imposes constraints the architecture must respect. An edge function gets a few milliseconds of CPU, a small memory ceiling, and a short wall-clock deadline; it cannot open a pooled database connection to a distant primary (the latency and connection count are both wrong), cannot hold large in-memory state, and cannot run long. These are not arbitrary — they are what let thousands of tenants share a PoP — but they mean the edge is for short, sharp, mostly-stateless work. Trying to run a heavy request handler at the edge fails on the budget; the design must keep edge functions lean and push weight to the origin.
The subtlest constraint is state. The origin has a strongly-consistent database; the edge has, at best, an eventually-consistent KV store that replicates writes out to PoPs with some lag, plus caches. This is fine for data that tolerates staleness — configuration, feature flags, cached content, session lookups — and wrong for data that must be immediately consistent across the globe, like a bank balance or an inventory decrement. The architecture has to sort every piece of state into 'edge-cacheable, staleness-tolerant' versus 'origin-authoritative, must-be-consistent,' and route reads and writes accordingly. Get that sort wrong and you either serve stale data as if it were fresh or drag every request back to the origin for consistency, losing the edge's whole point.
The architecture: every piece explained
Requests enter through anycast. The platform advertises the same IP from every PoP, and internet routing delivers each user to the nearest one by network topology. This is the mechanism that makes 'run near the user' automatic — the client resolves a normal hostname and its packets land at a close PoP without the client choosing anything. Anycast also gives free failover: if a PoP goes down, routing shifts users to the next-nearest one.
At the PoP, the request is handled by a lightweight runtime — most often a V8 isolate. Unlike a container or a traditional serverless function that may need hundreds of milliseconds to cold-start, an isolate spins up in about a millisecond and many thousands share a single process, isolated from each other the way browser tabs are. This is why the cold-versus-warm start distinction, while still real, is far less painful at the edge than in container-based serverless: even a cold isolate is fast. The runtime's lightness is exactly what allows the same code to be deployed to hundreds of PoPs affordably.
The code that runs is the edge function: the application logic you deploy to the edge. Its natural jobs are the latency-sensitive, compute-light ones — authenticating and validating requests, rewriting URLs and headers, personalizing responses and assigning A/B variants, issuing redirects, transforming images, and serving light API responses. It reads what state it needs from edge KV or cache: a key-value store replicated out to the PoPs and a content cache, both giving the function fast local reads of staleness-tolerant data — config, flags, sessions, cached content — without a trip to the origin.
When the edge cannot satisfy the request locally — a cache miss, data that is not at the edge, or work too heavy for the isolate — the function falls back to the origin: the region (or regions) where the real database, the large compute, and the authoritative state live. The origin does the irreducible stateful and heavy work and returns a response the edge can cache and relay. The design intent is that origin fetches are the exception, not the rule; the more requests the edge handles locally, the higher the origin offload and the bigger the latency win.
Two cross-cutting concerns shape everything. The per-request budget — a cap on CPU milliseconds, memory, and wall-clock time — is enforced by the platform and is what the function must live within; it is the reason edge functions are lean and the reason heavy work goes to the origin. Global observability is the discipline of collecting logs, traces, and metrics across hundreds of PoPs into one view, because a problem may live at one PoP or in one region and you cannot debug what you cannot see. The ops strip names the signals that matter: cold-start rate, edge cache hit rate, the percentage of traffic offloaded from origin, per-PoP error rate, and CPU-milliseconds per request against the budget — together these tell you whether the edge is fast, cheap, and healthy.
End-to-end flow
Follow a request from a user in Sydney to a service whose origin is in Virginia. The user's browser resolves the site's hostname and, via anycast, its packets arrive at the Sydney PoP tens of milliseconds away — not the origin 200 milliseconds across the Pacific. At the PoP, the platform routes the request into an isolate running the site's edge function; the isolate is either already warm from recent traffic or cold-starts in about a millisecond, so startup is negligible.
The edge function runs. First it does authentication: it validates the request's session token — verifying a signature, or looking up the session in edge KV, which holds a replicated copy of session data readable locally in microseconds. The token is valid, so the function proceeds without ever consulting the origin for auth. Next it personalizes: it reads a feature-flag configuration and an A/B assignment from edge KV — again staleness-tolerant data that lives at the edge — and decides which variant of the page this user gets. All of this has happened at the Sydney PoP with no transpacific round trip.
Now the function needs the page's content. It checks the edge cache: if the personalized content for this variant is cached at the PoP, it is returned immediately and the request is fully served from Sydney — the ideal case, high origin offload, minimal latency. Suppose instead it is a cache miss. The function falls back to the origin in Virginia, fetching the underlying data over one transpacific round trip, assembling the response, caching it at the edge for the next user, and returning it. Even here, the auth and personalization work stayed local; only the one unavoidable data fetch paid the distance.
Throughout, the function lived within its budget: a few milliseconds of CPU for the token check, KV reads, and response assembly, well under the wall-clock deadline. It did not open a database connection to Virginia (that would have blown the latency and connection budget); it read only edge-local state and made at most one origin fetch. Had the work required a real database transaction — say, decrementing inventory — the function would have delegated that entirely to the origin, because that state must be strongly consistent and authoritative, not eventually-consistent at the edge.
Step back and tally what the placement bought. Authentication, feature flags, A/B assignment, and cached content were all served from a PoP 20 milliseconds away, so the user's first byte arrived fast regardless of the origin's distance. The origin was consulted only on a genuine cache miss, so it was shielded from most traffic and its transpacific latency touched only the requests that truly needed fresh data. Every one of those wins came from correctly sorting the work — latency-sensitive and staleness-tolerant to the edge, heavy and must-be-consistent to the origin — and from keeping the edge function lean enough to run inside a millisecond-scale isolate budget. That sorting is the architecture; the platform provides the fabric, but where you draw the edge/origin line decides whether it pays off.