Durable Objects

Durable Objects give you single-threaded, strongly consistent compute and storage addressed by ID. It is an elegant answer to difficult coordination problems such as WebSocket rooms, counters, locks, and per-entity state. The programming model is beautiful from a computer science perspective, and it is easy to see why Cloudflare uses it internally.

Operations bring the score down to a 2. Each object lives on one machine at a time, so bad hardware can take a whole set of objects offline. If they coordinate something important, that layer is simply gone until placement recovers, and the customer has nothing useful to act on. There are plenty of traps: input/output gate deadlocks, storage growth that is hard to inspect, per-object throughput ceilings that appear in production, and observability that tells you too little about an unhealthy object. The length of Cloudflare’s own “Rules of Durable Objects” page says a lot about the product’s complexity.

The safe approach is to treat Durable Objects as a coordination cache you can afford to lose, never a system of record or a fleet’s single point of failure. I think they should have remained an internal primitive for Cloudflare rather than something customers build on. Their use beneath D1, Queues, Workflows, and Agents also makes me more cautious about those products.