The best backend primitive of the last decade is an object with a name.
That is the whole idea behind Cloudflare's Durable Objects: one single-threaded object per identity, addressed by name, with durable state attached. A shopping cart is an object. A chat room is an object. So is a game table, a device, a document, an agent run.
Calls to one identity run one at a time, so two requests can't corrupt the same cart. Calls to different identities run in parallel, so nobody waits behind a stranger. Kenton Varda's team shipped that and deleted a whole problem the rest of us usually solve with a database, Redis, a queue, and a fistful of locks.
I have spent twenty years building that pile of locks. I have built it in Rails apps, in Node services, and once, regrettably, in a spreadsheet importer. So when I finally internalized the Durable Objects model, I got a little angry. The model is too good to live behind one vendor's edge network.
I'm not alone in thinking this. Ryan Dahl's celld recreates the model as a self-hosted daemon: your VMs, your object-storage bucket, the Workers API without Cloudflare. It's excellent, and it proves the model has outgrown its birthplace. But celld answers the question at the infrastructure altitude. With celld you complicate your infrastructure by adding nodes and buckets and monitoring and scaling this new infrastructure.
