Durable Object
A Durable Object is a small piece of software on the internet that has its own identity and its own persistent storage, of which there is always only ever a single running copy worldwide. This design comes from the provider Cloudflare and solves a classic problem: multiple servers wanting to modify the same data at the same time.
When a website or app processes data, the program behind it usually doesn’t run on your phone, but on someone else’s computer on the internet. Such computers sit in large halls and serve many users at the same time. To keep things fast, providers often run the same program in parallel hundreds of times in many places around the world. This creates a problem: if two copies simultaneously change the same counter value or game score, the result is nonsense. A Durable Object is the answer to this. It is a small piece of software with its own name and its own storage, of which the provider guarantees that only a single active copy ever runs. The word “durable” refers to the fact that this piece of software remembers data beyond individual requests.
Why “only one copy” is a selling point
Programs on the internet are normally deliberately forgetful. They process a request and then forget everything again. Anything that needs to be remembered ends up in a database, i.e. a separate storage system. This works well, but becomes complicated as soon as many users change the same thing at the same time.
A typical example is a shared text document that five people are writing on at the same time. Without a central point that determines the order of changes, the edits overwrite each other. Developers otherwise solve this with locks and queues in the database. This is error-prone and hard to test. A Durable Object takes over this work, because uniqueness is guaranteed by the system itself.
The second advantage is speed. The storage belongs directly to the piece of software and is located in the same place. This eliminates the waiting time for the trip to a remote database. For applications where every millisecond counts, such as online games or live chats, this makes a real difference.
Name, address, and its own storage
Every Durable Object has a unique identifier, similar to a house number. Often something natural is used for this: the number of a chat room, the name of a document, the ID of a user account. When a request for “chat room 42” comes in, the system routes it to exactly the object with that identifier. No matter which part of the world the request comes from.
You can imagine this like a switchboard with extensions. All calls to a particular extension end up with the same person. This person keeps exactly one notebook, and no one else writes in it. That’s why the notes never contradict each other. If the extension doesn’t exist yet, the object is automatically created on the first call.
Requests to an object are processed one after another, not simultaneously. This means the developer doesn’t need to worry about concurrent access. If an object isn’t needed for a while, it goes to sleep and doesn’t cost any computing time. Its storage remains intact, however, and is there again on the next call. This is precisely where a Durable Object differs from an ordinary short-lived cloud function, which forgets everything after each request.
What products and news reports are talking about
The term almost always appears in connection with Cloudflare, a major provider of internet infrastructure. There, Durable Objects belong to the “Workers” platform, on which developers run their own program code in Cloudflare’s data centers. Other providers now have similar offerings, often under the buzzword “stateful serverless”, meaning “cloud programs with memory”.
In everyday life you encounter the result without seeing the term. Shared note-taking and drawing apps, live polls in streams, game rooms in browser games, or queues for ticket sales are often built this way. AI applications use it too: the conversation history of a chat with a language model has to be stored somewhere, and one object per conversation is an obvious solution for that.
The topic comes up in business news because such building blocks make providers either interchangeable or, indeed, not interchangeable. Anyone who relies heavily on Durable Objects for their app cannot easily move it to a different provider. Experts call this vendor lock-in. Another common misconception is that a Durable Object is a database. It’s more like a single responsible case worker with a small filing cabinet, not a system for millions of records and complex queries.