Load-testing a live awards game with 1,000 simulated players
A live game at a gala has one awkward property: everyone acts at the same moment. The screen says “Category starts now”, and a few hundred phones send a request within the same second. If the server stumbles there, it stumbles in front of the whole room.
For MEFMA’s awards night I built Guess the Winner, a prediction game guests play on their phones during the ceremony. It was built for about 500 guests. Before trusting it with a ballroom, I wanted to know what would happen with twice that number. This is how the test went, including the part that failed.
How the game works
Guests open a link, enter their table representative’s name and table number, and they’re in. There are three rounds: FM Client Awards with four questions, FM Service Provider Awards with five, and FM Supplier Awards with three. Twelve questions in total.
The host controls everything from a separate, password-protected screen. Starting a question puts it on every guest’s phone. Guests pick one of the four or five nominees, and their pick is saved as a draft until the host ends the question. Then the picks are submitted together.
Guests never see a leaderboard or the correct answers. The answer key is never sent to the browser at all, so nobody can find it by poking at the page. Scores are private to the host, with round totals, overall totals and CSV exports. The guest with the most correct predictions wins.
What could go wrong
Three moments carry most of the risk. The first is joining, when hundreds of people arrive at once. The second is the switch to a new question, when every phone has to update. The third is a round boundary, where phones may lose and regain connection.
So the test had to cover all three, through the same public HTTPS address guests would use, against the same server code. It also had to leave the real event data alone.
The first attempt failed
My first run used a load generator on a desktop machine, sending traffic over the internet to the live server. It joined all 1,000 simulated participants. Then it started opening the live connections that keep each phone in sync, and those started timing out on the way through Cloudflare, the service that sits in front of the website. It stopped after 203 of those connections opened. The slowest join took 7.7 seconds.
The public site kept answering its health checks the whole time. That suggested the bottleneck was the test machine and its route rather than the server. But a suggestion isn’t a pass. The run didn’t prove synchronisation, so it’s recorded as a failure and kept in the evidence alongside the run that passed.
The test that passed
The second run, on 10 September 2026, generated the load on the server itself, and still sent it through Cloudflare and the public web address. It used an isolated game on the same server with the same deployed backend code. Live participants and answers were not touched.
The simulated players behaved like the real guest app, including the small random delays real phones add and the backup checks the app makes when a live connection drops. They saved answers in bursts and played all three rounds.
Here is what it measured:
- 1,000 players joined at once. The slowest join took 761 milliseconds, under a second.
- All 1,000 stayed connected for live updates, and 50 were deliberately dropped and reconnected.
- On every one of the 12 question switches, all 1,000 phones caught up, the slowest in 572 milliseconds.
- At round boundaries, everyone was back in sync within about two seconds, including 50 players cut off on purpose for one and a half seconds.
- The test also ran the game’s optional 60-second timer: when a question expired, all 1,000 phones showed it closed within about half a second.
- 12,000 answers were stored, exactly 1,000 per question, with nothing left unsaved. The database check came back clean.
- A separate monitor checked the public site 92 times during the run. None failed.
- There were no unexpected disconnects and no restarts, and the whole run took 89.3 seconds.
Afterwards, the temporary test entry point was removed from the server.
A second test, for the voting rules
Speed isn’t the only risk. A game can be fast and still count votes wrongly. A separate test, with 500 simulated players on an isolated local setup, went after correctness.
It sent identical vote retries and checked they weren’t counted twice. It sent stale changes and checked they were rejected. It raced 500 votes against the host closing a question: 250 got in, 250 were refused, and the totals reconciled exactly. It restarted the server mid-game and checked that sessions, votes and scores survived. All 6,000 answers were stored and every score matched, including the rule that either of two joint winners earns a point.
What these tests don’t prove
The 1,000-player report says this plainly, and I think every load test report should. The load ran on the server. It does not reproduce 1,000 physical phones, venue Wi-Fi, how each device renders the page, every internet route, or hours of operation. Zero issues on the night can’t be guaranteed from a test like this.
The 500-player test has its own limits: it ran on a single local machine, with simulated players, and it didn’t cover the live hosting setup or venue Wi-Fi.
Writing those limits down can feel like weakening the result. In practice it tells the organiser what’s left to manage on the day, like the Wi-Fi in the ballroom, so a big number doesn’t stand in for certainty.
If your business has a rush moment
Plenty of businesses have a moment where everyone arrives at once: a ticket release, a product drop, the start of a live session, a sale that opens at 10am. If yours does, that’s the moment to test, on the real route, with honest limits written next to the result.
The questions I’d ask are simple. How many people at once, realistically and at worst? What do they all do in the first ten seconds? What happens if some of them lose signal?
If you have a moment like that coming up and want a second opinion on testing it, you can reach me on WhatsApp.
Related work: MEFMA Event Operations
