One Durable Object per room, and a rule that stranded a lecture hall

1 vs 100 is a live multiplayer quiz for a lecture hall: one person on stage against the crowd on their phones, everyone answering the same question against the same clock.

The first time it ran at a real faculty event, the vice dean was The One. About 45 students got into the game. The rest of the room was holding phones that showed every question and never offered a single button to press.

The server was fine. Nothing ran out of memory, nothing timed out. The game was doing exactly what I had told it to do.

Each game is one of Cloudflare's Durable Objects, addressed by the six-digit PIN on the projector. Every phone in the room opens a WebSocket to that one object, and that object is the only place the game exists.

A Durable Object handles one event at a time. A hall full of people answering in the same second cannot corrupt the scores, because there is never a second thread to race against. There are no locks in the code because there is nothing for them to protect.

There is also no shared database. The room keeps its own state in the object's built-in storage: the players, their scores, the question in flight. That is what lets a room survive being evicted from memory and pick up where it was. When the game ends, an alarm deletes the room's data. Each game is its own small database, and it lives exactly as long as the game.

Answers arrive in bursts, so broadcasts are batched, at most four a second, instead of one per answer. Idle sockets use WebSocket Hibernation, so a quiet room costs nothing. It runs on Cloudflare's free plan.

The game has knockout rounds. Get a question wrong and you are out. So I wrote a rule for late joiners that seemed obvious: if you join after the game has started, you watch. You cannot walk into a knockout halfway through and claim you survived questions you never saw.

In a test, that rule never fires. Everyone is already in the lobby when you press Start, because you are the one deciding when to press it.

A real lecture hall does not work like that. People are still walking in, still finding the QR code, still typing a name, when the host decides the room looks full enough. The host pressed Start with about 45 people in. Every phone that finished joining a second later was a spectator, for the whole game.

We kept the event going. Whoever had been stranded was carried into the next round by hand, so nobody lost their place for something that was not their fault.

Meanwhile I changed the rule, and deployed it during the event. In a round where nobody can be eliminated, a latecomer now joins as a full player immediately. In a knockout round they watch the current question and come in alive at the next one, so nobody is knocked out by a question they never saw. The only thing that keeps someone out for good is an actual elimination.

The part I am most glad of: anyone already stuck as a spectator did not have to do anything. When the next question started, the server brought them back in. By the following round, most of the room was playing.

Two players were knocked out who should not have been, and by the end of the event I did not know why.

It turned out not to be the server at all. Both had switched away from the tab in the middle of the game. When they came back, the phone reloaded the page, and in a knockout round that cost them their place.

That is the other half of the same lesson. A phone is not a test browser. It suspends tabs it is not showing, it reloads them when it wants the memory back, and nobody in a lecture hall keeps one tab open for an hour.

The architecture held. One object per room, no shared state, a single thread: none of that was the problem, and none of it needed to change.

What failed was an assumption about people. Practice is not the same as the real thing, and the difference is never in the parts you tested. It is the queue at the door, and the tab someone switched away from.