Edge Computing, CDN Compute & WebAssembly

Edge compute runs your code close to users

Edge compute runs your code in the CDN's points of presence (Cloudflare has hundreds worldwide), physically close to users, so a request can be answered without a round trip to a distant origin region. The headline is latency: time-to-first-byte under 50ms globally with no bespoke multi-region infrastructure of your own. But the thing that makes edge compute practical is not just location, it is the runtime.

V8 isolates and WASM

Container-based FaaS boots an OS-level sandbox per function, which is why cold starts are 100ms to 1s+. Edge platforms like Cloudflare Workers instead run V8 isolates: many tenants share one V8 process, each request gets a lightweight isolate (the same isolation a browser tab uses), and spinning one up is under 5ms, effectively no cold start. There is no VM or container to provision. WebAssembly (WASM) goes further: a precompiled WASM module can start in sub-millisecond time and lets you run Rust, Go, or C at the edge, not just JavaScript. The tradeoff for this speed is a constrained runtime: strict CPU-time budgets per request (tens of milliseconds of CPU, not seconds), small memory, and no full Node.js API surface (no arbitrary filesystem, limited native modules). You write to a web-standard API, not to Node.

What belongs where

Put at the edge the lightweight, latency-sensitive work on the request path: geo/device routing, auth and JWT verification (reject a bad token in the PoP instead of after a trans-oceanic hop), A/B assignment, header rewrites, personalization of otherwise-cached pages, bot filtering, and cache logic. Keep at the origin the heavy or stateful work: large database transactions, big compute, anything needing the full Node ecosystem, and any operation requiring strong consistency.

The edge data constraint

That last point is the real constraint. Edge data stores are built for reads-everywhere, not strong writes. Workers KV is eventually consistent with propagation that can take seconds; edge caches and regional read replicas serve stale-tolerant reads fast. Newer primitives shift the tradeoff: Durable Objects give you single-threaded strong consistency for one key by pinning it to one location (so you pay latency for writes to that object), and D1 offers a SQL database at the edge. But the general rule holds: you cannot get globally strong, low-latency writes for free, so edge data must be either read-mostly, eventually consistent, or explicitly pinned.

Interview nuance: the two failure modes interviewers listen for are (1) pushing heavy compute or a full Node app to the edge and hitting the CPU-time and API limits, and (2) putting strong-consistency data (balances, inventory, idempotency keys) in eventually consistent edge KV and getting stale reads or lost updates. Also flag that observability is harder: your code runs in hundreds of PoPs, so you lean on the platform's aggregated logs and tracing rather than SSHing into a box.

USER --> nearest PoP (V8 isolate, <5ms start / WASM <1ms)
            | route, auth/JWT, A/B, personalize, cache
            | strong-consistency data? --> origin
            v
          ORIGIN region: DB txns, heavy compute, full Node
   edge data: KV (eventual), read replicas, Durable Objects (pinned strong)

Recap: V8 isolates start in under 5ms and WASM sub-ms, so edge compute delivers global sub-50ms TTFB for lightweight request-path work like routing, auth, and personalization, while heavy compute and strong-consistency data stay at the origin because edge runtimes are CPU/memory/API constrained and edge data is eventually consistent by default.