Hey! I’m the PM for DO.
1) A Durable Object is a global singleton instance of a Cloudflare Worker that is addressed by an ID. You define that Worker’s behavior via a JavaScript class. That Worker can then write to a persistent storage API, which is backed by a strongly-consistent KV database.
2) yes, the storage API is strongly consistent.
As an example, say you had a Durable Object for each user’s configuration. You’d have a class called Config, and you’d access the Durable Objects associated with that class by calling their id from a Worker.
When a network request is received that routes your Worker, we’d run your Worker code in whatever datacenter we receive the request in.
If that Worker needs to access the user’s config data it would make a request for the Config Durable Object with that user’s id. That request is forwarded to a singleton Worker (which we call a Durable Object) running somewhere on our network. All of the requests for that User’s config data originating all across Cloudflare’s network will execute serially on that Durable Object, and can modify storage associated with the Object.
This means the Durable Object can both store state associated with the User’s config, but also expose methods and functions related to the user (for example, a function resetLogin() that resets their password).
3) while the DO has access to a KV storage API, they more closely resemble the Actor pattern or Azure’s Durable Entities.
4) they’re similar. Lambda@edge runs a container at a small number of AWS edge locations, while a Worker runs JavaScript or WASM code at a Cloudflare’s edge in response to a network request. Workers are much lighter weight, less expensive and have better performance characteristics, while supporting a smaller list of programming languages.
Let me know if you have more questions!