To the OP, I think you need to take a step back here.
What are the rooms for? What do they contain? Messages? State? Where is that information stored?
Do you need fault tolerance, or are the rooms ephemeral?
Assuming it’s not a big deal to “lose” a room, it’s okay to store each room’s state in one place, without worrying about replication or distributed consistency. Even just the user count is a piece of state.
Do you need to scale out? If not, you can just put all of the rooms in one ETS table on one node. Or in Postgres, or Redis, or whatever. That will probably scale into the millions.
If you do need to scale out, hash partition the rooms across nodes. When a user connects, choose a random node and ask that node to add the user to one of its rooms. The node knows the state of each room on that node, so it can pick one at random. Then if you need to look up any other state about that room, you can hash it and contact its node. If you need to handle nodes going down, use consistent hashing. Rendezvous is simpler than ring hashing.
When you pick a room to fill, finding the emptiest room is an expensive operation (there could be millions of rooms). Use the old load balancing trick: pick two at random and fill the emptier one. It’s near-optimal.
