For the use cases that Waiting Room is designed for, "just design for scale" is really not so simple.

In a "typical" web app, you have a stateless web server backed by a distributed database. Each user mostly interacts with their own data, or collaborates with a few other users. In this case, scaling is "easy": just add instances, to both the web server and the database.

But now imagine you're trying to distribute a limited number of vaccine appointment slots (or concert tickets, or whatever) to a huge number of people. This is a very different problem, because everyone is accessing the same data. "Just add instances" may work for your web server layer, but it won't necessarily help at the database layer.

The most scalable distributed databases are eventually consistent ones. But you can't use those here. You can't afford to accidentally give two people the same appointment slot. So, you absolutely need strong consistency.

But strongly-consistent databases will typically have an inherent limit on how many clients can be accessing the same data at the same time. For any one piece of data, there will typically be 3-to-5 designated nodes which form the consensus group for that piece, and at least a quorum of those must each track every single change. That means the throughput of transactions on a single key in the database is limited to what a single machine can process.

With really careful database tuning, you might be able to make it work. Perhaps you could carefully ensure that appointment slots are well-distributed across chunks, and make sure to utilize replicas for read operations that don't necessarily need up-to-the-moment consistency. It might work... but needless to say, to most developers a database is a black box, and they have no idea how to think about this kind of tuning.

Durable Objects don't magically solve this. They do make "chunks" much more explicit, which might make it easier to think about how to build a scalable solution. But each object has that same inherent scalability limit as a database chunk. Durable Objects are a building block; you still need distributed systems skills to utilize them properly for these kinds of problems.

Meanwhile, the kinds of people that have these problems to solve -- local governments, event venues, etc. -- aren't exactly the types of people who employ distributed systems experts.

(And even if we did magically have infinitely scalable technology, you still have a problem: humans. If everyone is fighting over the same appointment slots, how do you make sure you aren't just rewarding the person who clicks fastest?)

The genius of Waiting Room is that you can hire any random contractor to build your web app, and then you make it scale by slapping Waiting Room on top. There's no need for a distributed systems expert to think about your use case. You don't even have to do much of a load test. (And you don't have to worry that your event will be overrun by professional StarCraft players.)

I actually do think this is a great use of engineering talent at Cloudflare, to have one group of distributed systems experts solve the problem in a general way that everyone can then easily apply to their own sites.

(Disclosure: I am the tech lead for Cloudflare Workers. Waiting Room was built by a separate team.)