Edge Computing (Cloudflare Workers, Lambda@Edge, Deno Deploy)

TL;DR: Edge computing runs application code in hundreds of PoPs rather than a handful of regions. Cloudflare Workers operates in 330+ cities with sub-5 ms cold starts by sharing one V8 process across thousands of tenants ¹. The appeal is latency: compute within milliseconds of most Internet-connected users ². The trap is assuming that moving code closer to users also moves data closer. It does not. Successful edge applications are hybrid: stateless transforms at the edge, system of record at the origin, and carefully chosen stateful primitives (Durable Objects, D1, Turso) bridging the gap.

Learning Objectives

After this module, you will be able to:

• Describe the three dominant edge runtime models and their execution constraints
• Explain Durable Objects and how they enable stateful edge computing
• Choose between global-regional-edge tiers for a given workload
• Design edge data access patterns using D1 Sessions, KV, and Hyperdrive
• Avoid anti-patterns: heavy compute at edge, chatty back-to-origin calls, KV as transactional store

Intuition

You run a chain of coffee shops across 330 cities. Each shop has a barista (compute), a small display case (cache), and a menu board (config). Customers get their coffee in seconds because the shop is on their block.

But the shops do not roast their own beans. Every night, a truck delivers fresh beans from a central roastery (the origin). If a customer orders a rare single-origin pour-over that is not in stock, the barista calls the roastery and the customer waits for a courier. The shop is fast for common orders and slow for rare ones.

Now imagine one special shop in each region that keeps a ledger of loyalty points. Every customer worldwide has exactly one ledger, pinned to one shop. If you are near that shop, checking your balance is instant. If you are across the ocean, you wait for the call to cross the water. That ledger is a Durable Object: one instance, one location, strongly consistent, but not magically global.

Edge computing works the same way. The PoP is the coffee shop. The barista is a V8 isolate with a tight CPU budget (10 ms on the Free plan, 30 s default on Paid). The display case is the edge cache. The roastery is your origin database. And the loyalty ledger is the stateful primitive that makes the edge more than a glorified CDN. The rest of this chapter makes these ideas precise.

Theory

Edge runtimes and cold starts

CDNs and Edge Delivery introduced the CDN as a cache layer. Edge computing extends that layer with programmable request handling. Three runtime families dominate:

V8 isolates (Cloudflare Workers, Deno Deploy, Vercel Edge Functions) share a single V8 process across thousands of tenants on one machine. Context-switching between isolates requires no OS-level process switch. Cold start is approximately 5 ms and memory overhead is roughly 3 MB per tenant, compared to 35 MB for a Node.js Lambda container ¹. The trade-off: code must target JavaScript, TypeScript, or WebAssembly. No native binaries, no arbitrary system calls.

WebAssembly sandboxes (Fastly Compute) compile tenant code to Wasm and spin a fresh Wasmtime sandbox per request ³. This gives the strongest per-request isolation and true polyglot support (Rust, Go via TinyGo, JavaScript via Javy). Cold starts are on the order of microseconds for lightweight functions.

MicroVM platforms (AWS Lambda@Edge, Fly.io via Firecracker) boot a hardware-virtualized VM per tenant. Full OS semantics, any language, but cold starts of 50 to 100 ms and higher memory overhead ⁴.

flowchart LR
    subgraph "Cloudflare Workers machine"
        P[V8 process] --> I1[Isolate A<br/>~3 MB]
        P --> I2[Isolate B<br/>~3 MB]
        P --> I3[Isolate C<br/>~3 MB]
        P --> IN[... thousands more]
    end
    subgraph "Lambda@Edge host"
        P1[Node process A<br/>~35 MB]
        P2[Node process B<br/>~35 MB]
        P3[Node process C<br/>~35 MB]
    end

The CPU budget is the constraint that shapes everything. On the current Workers Standard plan, each HTTP request defaults to 30 seconds of CPU time and can be raised up to 5 minutes; the Workers Free plan caps CPU at 10 ms per request (wall-clock time during await does not count toward CPU time) ⁵. The legacy Bundled plan’s 50 ms CPU ceiling remains on grandfathered Workers but is no longer the default for new deployments. CloudFront Functions are far tighter: sub-millisecond execution, 2 MB memory, 10 KB code, ECMAScript 5.1 only ⁶. Lambda@Edge allows up to 30 seconds but deploys only to CloudFront’s 15 Regional Edge Caches, not to every PoP ⁶.

Stateful edge with Durable Objects

Most edge runtimes are stateless by design. Durable Objects (DOs) break that rule. A DO is a single-instance, named, locality-bound actor with private SQLite storage ⁷. Every request for a given name, from anywhere in the world, routes to the same instance on the same machine.

SQLite runs in the same thread as application code. Queries execute synchronously in microseconds because the database is a library call, not a network hop ⁷. The absence of await between a SELECT and an UPDATE is the correctness property: no concurrent request can interleave because JavaScript is single-threaded and the “input gate” holds other events during an await.

Writes are asynchronously replicated to five “durability follower” machines in different datacenters via Cloudflare’s Storage Relay Service. The “output gate” holds the Worker’s response until at least 3 of 5 followers acknowledge the write ⁷. This guarantees durability without blocking application code.

sequenceDiagram
    participant Client
    participant Worker as Edge Worker (PoP)
    participant DO as Durable Object (home colo)
    participant SQL as SQLite (in-thread)
    participant F1 as Follower 1
    participant F2 as Follower 2
    participant F3 as Follower 3
    Client->>Worker: POST /write
    Worker->>DO: stub.fetch()
    DO->>SQL: INSERT (sync, microseconds)
    DO->>DO: Response constructed
    par Replicate WAL frame
        DO->>F1: WAL frame + bookmark
        DO->>F2: WAL frame + bookmark
        DO->>F3: WAL frame + bookmark
    end
    F1-->>DO: ack
    F2-->>DO: ack
    Note over DO: Output gate opens (3/5 quorum)
    DO-->>Worker: Response released
    Worker-->>Client: 200 OK

WebSocket hibernation extends DOs for real-time use cases. Using ctx.acceptWebSocket() instead of ws.accept(), the runtime can evict the DO from memory while keeping TCP connections open at the edge. The DO wakes only when a message arrives ⁸. A chat room with 10,000 idle connections incurs zero duration charges until someone speaks.

The single-writer property is the feature, not the bug. It eliminates distributed coordination for per-key state: rate limiters, session stores, collaborative document locks, game lobbies. But a DO pinned in North America serves European users with 100+ ms cross-Atlantic latency on every request. Use locationHint or region-prefixed naming to control placement.

Edge databases and storage

Edge databases solve the read path. Writes still bottleneck at a primary, but reads can be served from nearby replicas.

D1 is Cloudflare’s SQLite-backed edge database. Under the hood, each D1 database is a Durable Object with automatic read replicas in every supported region ⁹. The Sessions API provides read-your-writes consistency: every write returns a monotonic “bookmark” (a Lamport timestamp). Clients pass that bookmark on subsequent reads, and replicas wait until they have replayed up to that point before answering ⁹. Confirm lag from ENAM primary to WEUR replica is approximately 55 ms ⁹.

sequenceDiagram
    participant C as Client
    participant W as Worker + D1 binding
    participant P as Primary (WNAM)
    participant R as Replica (EEUR)
    C->>W: POST /order (no bookmark)
    W->>P: INSERT Orders
    P-->>W: ack, bookmark=100
    W-->>C: 200 OK, x-d1-bookmark=100
    C->>W: GET /orders, x-d1-bookmark=100
    W->>R: SELECT, wait until WAL >= 100
    Note over R: Block until WAL replayed to 100
    R-->>W: rows, bookmark=104
    W-->>C: 200 OK, x-d1-bookmark=104

Workers KV is an eventually-consistent global key-value store. Reads from a cached PoP are served with low latency. Writes propagate asynchronously. It is designed for “mostly read, occasional write” patterns like feature flags and configuration. It is not transactional and has no compare-and-swap.

R2 is S3-compatible object storage with zero egress fees ¹⁰. At $0.015/GB-month storage and $0 egress, it undercuts AWS S3 dramatically for read-heavy workloads.

Hyperdrive is a connection pool and query cache for external PostgreSQL/MySQL databases. It routes queries over Cloudflare’s backbone, reducing connection overhead and caching read results at the edge. It does not make a regional Postgres global; it makes accessing one faster from the edge.

Turso uses libSQL (a SQLite fork) with “embedded replicas” that maintain a local SQLite file synced from a cloud primary ¹¹. Reads are zero-latency (local file); writes go to the primary. This is the closest thing to a true edge-first database today.

Patterns that work at the edge

Edge cache with stale-while-revalidate. Serve stale content instantly while refreshing in the background. Combined with Tiered Cache (funneling PoP misses through an upper-tier cache before hitting origin), this eliminates thundering-herd storms on TTL expiry.

Edge API gateway. Auth token validation, rate limiting, request routing, and header manipulation all fit comfortably within a handful of milliseconds of CPU time, well under the Standard 30-second default. The edge becomes a security and routing front door without adding origin latency.

Edge SSR and React Server Components. Shopify Hydrogen renders storefronts on Oxygen (Cloudflare’s workerd runtime). Vercel’s Fluid Compute pre-warms instances and uses in-function concurrency to share the JavaScript engine cost across requests ¹². First byte arrives within tens of milliseconds of the user.

Smart routing. Cloudflare’s Smart Placement automatically moves a Worker closer to its origin when the Worker makes more subrequests than it serves directly. This is the escape hatch for Workers that are accidentally chatty.

Edge ML inference. Workers AI bindings let you call inference models without shipping weights to the edge. The model runs on Cloudflare’s GPU fleet; the Worker orchestrates the request.

When NOT to use edge

The edge is a hybrid tier between CDN and origin. It is not a replacement for either.

Heavy compute. Image processing, PDF generation, video transcoding, and ML training all exceed the CPU budget. Offload to containers or origin.

Chatty origin calls. An edge handler making 8 sequential fetch() calls to us-east-1 gives a user in Singapore 8 x 200 ms = 1.6 seconds. Moving the handler to the edge made latency worse, not better. Co-locate data with compute, batch calls, or use Smart Placement.

Synchronous fan-out. Aggregating responses from 5 microservices at the edge serializes cross-ocean round trips. Do the aggregation at the origin where services are colocated.

Strong consistency across regions. If every request must read the latest write globally, the edge adds a hop without reducing latency. Keep the request at the origin where the primary lives.

Real-World Example

Shopify Hydrogen on Oxygen: edge-rendered storefronts

Shopify’s Hydrogen is a React-based storefront framework. Oxygen is the hosting platform that runs Hydrogen on Cloudflare’s workerd runtime, deployed globally across Cloudflare’s network ¹³. Every paid Shopify plan includes Oxygen at no extra infrastructure cost.

The architecture is straightforward: a Hydrogen storefront is a Worker. It receives a request at the nearest PoP, renders React Server Components, fetches product data from Shopify’s Storefront API (cached aggressively at the edge), and returns personalized HTML. The local development server replicates the production Workers runtime exactly, so what runs locally runs in production.

flowchart LR
    U[User] -->|anycast| POP[Edge PoP<br/>workerd + Oxygen]
    POP -->|cache hit| U
    POP -->|cache miss| SF[Shopify Storefront API<br/>regional origin]
    SF --> POP
    POP -->|rendered HTML| U
    POP -.->|KV/R2| S[Static assets<br/>zero egress]

Why this works: product catalog pages are read-heavy with predictable data shapes. The CPU cost of rendering a React component tree fits within the Worker budget. Writes (cart updates, checkout) route to Shopify’s regional origin where transactional guarantees live. The edge handles the 95% of traffic that is browsing; the origin handles the 5% that is buying.

Trade-offs

Common Pitfalls

Exercise

Design the rate-limiting logic for a public API that needs to enforce “100 requests per minute per API key” globally. The naive implementation hits a central Redis; at the edge you want sub-10 ms latency. Design a solution using Durable Objects (one object per API key, pinned to the first region that sees the key) and reason about what happens when a client migrates regions mid-minute.

Key Takeaways

• Edge shines when latency matters and the work is small. It fails when you treat it as a cheaper origin.
• V8 isolates eliminated cold starts as a blocker (~5 ms vs 50 to 100 ms for Lambda@Edge), but the per-request CPU budget (10 ms on Free, 30 s default up to 5 min max on Paid) still shapes what you can do per request ¹⁵.
• Durable Objects are single-instance actors with embedded SQLite. The single-writer property eliminates distributed coordination for per-key state ⁷.
• D1’s Sessions API provides read-your-writes consistency via monotonic bookmarks. Without it, reads fall back to eventual consistency with no guarantees ⁹.
• R2’s zero-egress pricing makes edge-served static assets dramatically cheaper than S3 at scale ¹⁰.
• The edge is additive to a regional origin, not a replacement. Most successful edge apps are hybrid: stateless transforms at edge, system of record at origin.
• Pick a consistency story explicitly: read-your-writes (D1 Sessions), eventual (KV), or strong single-writer (Durable Objects). Silence here creates bugs.

Further Reading

• Cloud Computing without Containers - Cloudflare’s 2018 argument for V8 isolates over containers; still the clearest statement of why the model matters and how it enables deploying every Worker to every PoP.
• Zero-latency SQLite storage in every Durable Object - Kenton Varda’s deep dive on Storage Relay Service, output gates, and why SQLite lives in the same thread as application code.
• Sequential consistency without borders: how D1 implements global read replication - The bookmark/Sessions API design with actual measured confirm-lag numbers across regions.
• AWS CloudFront Functions vs Lambda@Edge - The canonical comparison table; note the 10 KB code limit and 10,000 RPS ceiling on Lambda@Edge.
• The Anatomy of an Isolate Cloud - Deno’s take on V8-isolate architecture with extra security layers (seccomp, process-per-deployment).
• How We Built Oxygen - Shopify’s engineering post on running Hydrogen on Cloudflare’s workerd runtime at global scale.
• Turso Embedded Replicas - SQLite replica in the application process itself; local-first with cloud sync for the edge-first database pattern.
• workerd GitHub repo - Cloudflare’s open-source Workers runtime (Apache 2.0); read the README for design principles and the “not a hardened sandbox” warning.

Flashcards

References