The Tech Behind a Live Game Night: What Happens When 60 Phones Answer at Once

From a player's seat, a live round is four options and a countdown. From the server's seat it is sixty devices on unreliable bar Wi-Fi, all trying to answer the same question in the same two seconds, each convinced its own clock is correct. Here is how that is actually held together.

One clock, and it is not yours

The single most important design decision in a live game is that the timer lives on the server. Phones display a countdown, but they do not own it. If a device's clock is skewed, if its screen sleeps, if it reconnects mid-question, the authoritative answer to 'was this in time?' is decided in one place. Client-side timers are how you end up arbitrating a dispute at the bar at eleven at night.

The answer key never leaves the server

Questions and options are pushed to devices. Correct answers are written to a server-only store that no client can read, and they are compared server-side. This is not paranoia — anything sent to a phone can be inspected, and a trivia night with a $50 tab on the line is exactly the environment where someone will try. It is the same principle that decides what to ask a trivia software vendor.

Fan-out, and why sticky sessions matter

Live state travels over WebSockets: question pushes, answer receipts, score updates, the leaderboard. That means every phone in a game must stay connected to the instance that holds that game's state — so the deployment runs with session affinity turned on. It is an unglamorous infrastructure flag that quietly decides whether the whole thing works.

• Server owns the clock; clients only render it.
• Answer keys live in a store clients cannot read.
• All score writes go through the server, never the client.
• WebSocket state is pinned per game via session affinity.
• Reconnects rejoin the round in progress instead of dropping the player.

Designing for a bad network on purpose

Bar Wi-Fi is congested, and a room full of people streaming is the worst case. So the assumption is failure: a dropped socket reconnects and re-syncs into the current question rather than ending the player's night, and a late answer is judged against the server's window, not the phone's. Testing this properly means testing in an actual bar, which is one of the reasons the studio builds where its first customers are.

Assume the network fails mid-question, because on a busy night it will.

The AI sits behind all of this, not in front of it

Question generation runs ahead of play, off the critical path, so a model call is never between a player and their countdown. Rounds are prepared and validated before the game starts — the details are in how AI writes a fresh round. The live path stays boring, which is the highest compliment you can pay a real-time system.

All of it — game engine, AI pipeline, apps and dashboards — is built and operated by Impartial AI Tech. If you are building something with similar real-time or AI requirements, or just want to see the rest of the studio's work, start at impartialaitech.com.