https://blog.cloudflare.com/introducing-workers-durable-obje...
Durable Objects aren't exactly the same as Erlang actors (which is why we don't usually call them "actors" -- we found it led to some confusion), but at some level it's a similar concept.
You can easily have millions of Durable Objects in a Workers-based application.
Currently workerd has partial support for Durable Objects -- they work but data is stored in-memory only (so... not actually "durable"). The storage we use in Cloudflare Workers couldn't easily be decoupled from our network, but we'll be adding an alternative storage implementation to workerd soon.
They remind me of this article: http://ithare.com/scaling-stateful-objects/
One critical thing that I couldn't find info about is what reliability to expect from the persistent storage for a Durable Object. Is it more or less a write to a single disk without redundancy? If there's redundancy, to what degree? Essentially, how much would you need to build on your own in terms of replication for a production scenario if using Durable Objects as primary storage?
I get that they can use other, separate storage if necessary, but either way it seems like an important consideration when designing a system on top of them.
The fact that there is one unique instance of the object live at a time (and therefore only one client for the distributed storage) lets us do a lot of tricks to hide the storage latency.
https://blog.cloudflare.com/durable-objects-easy-fast-correc...