Edge computing + Durable Objects: the edge-first architecture

In 2025, Cloudflare operates more than 330 POPs across 125 countries. AWS counts about 35 regions for Lambda, and Vercel builds on 18 edge regions. The consequence, measured from our VALRY LABS test benches: a user in Paris, Berlin, Milan, or Madrid reaches a Cloudflare POP in under 25 ms RTT (median p50 via cloudping and internal tests). On the European market, the 50 ms threshold — below which a user perceives an interface as instant — is met for roughly 95% of internet users.

What this changes concretely: the "primary database in one region, read replicas elsewhere" pattern becomes a costly opportunity, not a standard. For read-heavy, collaborative, or latency-sensitive workloads (chat, presence, real-time dashboards, light AI), running the code where the user is now beats any well-tuned regional architecture by 60 to 150 ms. That's the gap between a UI that feels fluid (INP < 100 ms) and one that feels "distant".

Beware the narrative trap: edge does not mean "stateless". For years, the edge was mostly stateless (CDN, rewrites, caching). What changed in 2024-2025 is the arrival of a strongly consistent stateful primitive — Durable Objects — and edge-friendly serverless databases (Turso, Neon, PlanetScale). Edge-first is no longer a slogan; it is a traceable, billable, production-viable architecture.

Workers uses neither containers nor micro-VMs: every request is served by a V8 isolate (Chrome's engine) shared between thousands of tenants on the same host. Average cold start is around 5 ms (0 ms measured at p50, ~5 ms at p99 per Cloudflare benchmarks, confirmed by our own measurements on a "ping" Worker). For comparison, Lambda@Edge starts between 200 and 800 ms at p95 — a gap that makes Workers almost mandatory on the user-critical path.

On the developer experience side: a Worker is a TypeScript file, deployable via `wrangler deploy` in under 10 seconds, with typed bindings (KV, R2, D1, Queues, Durable Objects, AI, Analytics Engine). No AMI, no Dockerfile, no blue/green to orchestrate. For a team of 5 to 15 developers — VALRY LABS' target — deployment friction drops to the level of a `git push`. Code reviews focus on logic, not infrastructure.

The flip side: a constrained execution model. CPU time capped at 30 s (paid tier), memory at 128 MB, no `fs`, no `child_process`, no raw sockets. You don't write a video-processing worker. You write orchestrations, routing, payload transformations, Zod validation, fan-out. For CPU-heavy workloads, delegate to a regional backend or to Cloudflare Containers (released 2025), not to a Worker.

Durable Objects (DO) is the primitive that turns Workers from "stateless function" into "distributed object platform". A DO is a single, globally addressable instance with private state and strongly consistent transactional storage. Concretely: for a given identifier (say `room:project-42`), only one live instance exists at a time worldwide, and every write is serialised through that instance. It's the actor model (Erlang/Akka) brought within reach of a product team.

The built-in storage (`ctx.storage`) offers a transactional key-value API with strong consistency, at 10 ms latency for a `put`/`get`. No need for an external Redis or a dedicated Postgres to orchestrate a distributed counter, a WebSocket room, or a global rate limiter. The DO carries state, code, and consistency in a single perimeter, and automatically migrates to the POP closest to the last writer.

Use cases where DO shines: real-time collaborative editors (centralised CRDT or OT), global rate limiters (Cloudflare itself uses DO for its native Rate Limiting product), presence and online indicators, multiplayer game matchmaking, per-user priority queues, session registries. On these workloads, the "Postgres + websocket gateway + Redis pub/sub" alternative typically means 4 services to operate. A DO replaces them with a 150-line TypeScript class.

Three patterns cover 90% of the workloads we see in premium B2B. Pattern 1 — edge-first with a regional database as fallback: a Worker out front for auth, routing, transformation, KV caching, and reads/writes against an edge-friendly serverless database (Turso for distributed SQLite, Neon for multi-region replicated Postgres, PlanetScale for MySQL). p50 latency of 30 to 70 ms for 95% of users, contained ops complexity.

Pattern 2 — edge + Durable Object for stateful workloads: every session/room/document is backed by a DO. The Worker routes to the DO via `env.MY_DO.idFromName(roomId)`. The DO holds the hot state (cursor positions, presence, locks) and periodically persists to the regional database (snapshot, audit, archive). This is what Figma implements with a similar architecture (centralised objects per document, edge for rendering) and what Discord uses for presence via Cloudflare.

Pattern 3 — edge + Queues for async: a Worker receives the request, writes a message to Cloudflare Queues, and immediately returns 202 Accepted. A consumer Worker processes in the background (PDF generation, third-party API calls, outbound webhooks, AI embeddings). Perceived latency < 50 ms, throughput absorbed without backpressure at the edge. Combine with Cloudflare Workflows (released 2025) for multi-step pipelines with retries and long durations.

The database question comes up early. Rule of thumb: if the data is mostly-read with slow invalidation → KV (edge cache). If it's relational and requires SQL → Turso (edge SQLite), Neon (edge Postgres), or PlanetScale (edge MySQL). If it's strongly stateful and collaborative → Durable Objects + periodic snapshots to Neon/PlanetScale. And for heavy analytical workloads, stay in-region: BigQuery, ClickHouse, and Snowflake don't live at the edge.

Figma (publicly documented in their engineering talks) uses a centralised-objects-per-document pattern that foreshadows Durable Objects: a single instance per multiplayer file, automatic migration to the datacenter closest to activity, CRDT-diff synchronisation. The lesson: a fluid collaborative editor at global scale cannot be built with a central Postgres and websockets — you need a stateful actor per document, exactly the DO model.

Discord uses Cloudflare to serve its presence layer to several hundred million simultaneous users. The challenge: knowing who is online, in which server, on which channel, without drowning the databases. The edge layer absorbs heartbeat noise and aggregates state before pushing to the backend. It's a textbook example of edge/region division of labour: the edge handles volume and freshness, the region handles durable persistence.

Cloudflare itself relies on Durable Objects for its managed Rate Limiting product (announced and documented 2023-2024). Every rate-limit bucket is a DO addressed by `bucket:user-or-ip`, with a transactional counter. This lets Cloudflare enforce globally consistent limits without depending on central Redis, and scale to millions of buckets without manual operations. A textbook case of the DO primitive.

For our VALRY LABS clients, the most immediate use case is the real-time dashboard: one DO per dashboard aggregates incoming webhooks (Stripe, Linear, Vercel, Sentry), computes aggregates, and pushes deltas via WebSocket/SSE to connected viewers. Typical event-to-screen latency: 80 to 150 ms worldwide, versus 400 to 900 ms with a regional gateway. For production or revenue-ops KPIs, the gap is perceptible — and commercial.

Durable Objects has a pricing model worth knowing. As of late 2025: $12.50 per million requests to DOs, $12.50 per million `alarm()` calls (built-in scheduler), and above all $12.50 per million "duration-seconds" (time billed per second, capped per DO). Storage is billed at $0.75/GB/month, and every storage operation (get/put/list/transaction) costs about $1 per million. On a typical collaborative-chat workload (100 active rooms, 50 msgs/s each), you land around $80 to 150/month — reasonable. On an aggressive-polling workload (1 request/second per connected user), the bill climbs fast.

The technical limits deserve tracing: 1 MB maximum per storage key (beyond that, fragment or use R2), 1000 Durable Objects per Worker (a "soft" limit, raisable on request), 128 MB of memory per DO, 30 s of CPU per request, no `setTimeout` beyond the request's lifetime (use `alarm()` for durable scheduling). These ceilings aren't prohibitive, but they impose design discipline: small objects, hot state in memory, batch persistence, alarms for TTL.

The cost decision rule: edge wins when user latency is critical and per-session load is moderate (chat, presence, dashboards, short AI). Region wins when per-session load is heavy (ETL, ML training, analytical reporting, batch) or when you already have deep Postgres/warehouse investment. At 10 sustained req/s, edge costs $5 to 15/month. At a million requests per minute, edge can cost 3 to 10 times more than an autoscaled regional VM — worth pondering before pushing everything to Workers.

Our operational decision framework: (1) Read-heavy, global, data < 1 MB → KV + Worker. (2) Real-time collaborative stateful, hot state < 128 MB → Durable Object + snapshots. (3) Heavy CPU or relational DB workloads → region (Neon/PlanetScale + regional compute). (4) Async workloads → Queues + consumer Workers. (5) In doubt about volume → start in-region, migrate to the edge only the path that shows up in latency. That path saved us a complete refactoring on two clients in 2025.

For 2026, we anticipate three concrete shifts among our premium B2B clients. First, edge-first will become the default for all read-heavy, collaborative, and light-AI workloads (classification, short embeddings, routing). The marginal cost of edge has dropped enough that the trade-off now plays out on latency, not budget. Next, serverless edge databases (Turso, Neon, PlanetScale) will reach the maturity to serve as the primary transactional foundation on 70% of projects — not just caching.

Then, Durable Objects will become banal as the reference primitive for stateful workloads. With SQLite in DO (announced 2024, generalised 2025), a DO becomes a mini local SQL database at the POP, strongly consistent, replicating to the region in the background. That primitive didn't exist 18 months ago, and it changes the equation for collaborative editors, per-user file processing, and any hot state with relational structure.

Finally, the edge/region split will clarify: edge for the user-critical path (latency, hot state, presence, routing), region for heavy workloads (analytics, ETL, ML, long persistence, GDPR compliance on sensitive data). For architects, the 2026 job is not choosing edge OR region, but drawing the clean boundary between the two — and being able to justify every workload placement with a latency number, a cost number, and a risk number.