Summary
I recorded this video to share the insights I gathered this week about Cloudflare Workers and Durable Objects (DOs) as we evaluate different strategies for splitting a DO. I start by outlining the global edge network—330 Cloudflare PoPs using anycast routing—so requests are automatically routed to the nearest data center. I then dive into the Workerd runtime on each Linux server, explaining how it hosts many V8 isolates, each limited to a 128 MB private heap, and how paid and free customers are segregated into separate runtimes. Next, I walk through the request flow: an inbound proxy receives traffic, maps hostnames to worker scripts, hands the request to Workerd, which either uses an existing isolate or asks a supervisor to fetch the script and spin up a new isolate; the response then passes through an outbound proxy. I highlight why this architecture makes Workers extremely fast—isolates start in a few milliseconds compared to the heavier startup of traditional serverless platforms. Finally, I clarify the terminology around scripts, versions, and deployments, and emphasize a critical limitation: instances of different DO classes can never share the same isolate, so each DO class must run in its own isolate. This constraint is essential when designing a split‑DO approach to manage memory pressure and deployment impact.
andrew
5d ago
Correction: "V8 restriction" should be "V8 level restriction". V8 just gives workerd the knob it needs to limit memory to 128mb, but it doesn't do that by default