Durable Objects

Durable Objects give you single-threaded, strongly consistent compute-plus-storage primitives addressed by ID — an elegant answer to coordination problems that are genuinely hard everywhere else. WebSocket rooms, counters, locks, per-entity state: from a comp-sci perspective the programming model is genuinely beautiful, and it’s obvious why Cloudflare builds so much of its own platform on them.

The operations story is why the score is a 2. Each object lives on exactly one machine at a time, so a single bad metal can take a whole set of objects offline — and if those objects are orchestrating something important, that orchestration layer is just gone until placement recovers, with nothing actionable on the customer side. The footguns and gotchas are everywhere: input/output gate deadlocks, unbounded storage growth with no great tooling to inspect it, per-object throughput ceilings that only reveal themselves in production, and observability that says far too little about where an object is or why it’s unhealthy. Cloudflare’s own docs make the case: when the official “Rules of Durable Objects” best-practices page is that long, the product is probably too complex for most use-cases.

The safe pattern: treat DOs as a coordination cache you can afford to lose, never as a system of record, and never as a single point of failure for a fleet. Honestly, they should have remained an internal primitive Cloudflare builds products on — not a product customers build on. The fact that so many newer Cloudflare products (D1, Queues, Workflows, Agents) sit on top of them is a main source of skepticism about those products too.