I love seeing more options appear on the horizon for doing stateful serverless work. This article[1] provides a little more motivation for the use cases: > For

I love seeing more options appear on the horizon for doing stateful serverless work. This article[1] provides a little more motivation for the use cases: > For quite a long time (and especially in the webdev world), there exists a perception that to achieve scalability, all our request handlers need to be as stateless as possible. In the world of the all-popular Docker containers, it means that all the app containers need not only to be immutable, but also should be ephemeral ... keeping our request handlers stateless, does NOT really solve the scalability problem; instead it merely pushes it to the database. Though the problems and solutions pointed out in that article don't mean you have to go straight to process-per-X. One solution might be, as mentioned in passing in the OP's launch blog, to keep state in a cache like Redis. If the data fits this approach, it would ease load on the database while allowing each request handler to remain stateless. Durable Objects seem less focused on heavy computation, but I think they're really interesting as points of synchronisation for e.g. collaborative editing. Having all requests go into a _single thread_ seems important. [1]: http://ithare.com/scaling-stateful-objects/ http://ithare.com/scaling-stateful-objects/