Olimpijski Kviz

A QR code goes out on the broadcast. Thousands of people scan it in the same moment, land in the same lobby, see the same question appear, and get fifteen seconds to answer it. Then the leaderboard resolves for all of them at once, and the next question starts.

There is no second take. If the screens drift apart, or the leaderboard lags, or one question round buckles, it happens on air in front of the audience. And the whole thing had to exist in about four weeks, because the Games were not going to move.

• Sixteen quizzes, one per broadcast night between 6 and 21 February
• Sixteen questions a night, four choices, fifteen seconds each
• Scoring is timed by the server's own clock, so a device cannot lie about when it answered
• A double tap or a retry on a flaky connection cannot count twice

The usual answer to live synchronisation is a socket per player. We never opened one. Every phone asks the server what it should be showing, about once a second, over ordinary HTTP. The server answers from a state machine that a single clock drives through its phases, from lobby to question, sponsor break, waiting, standings and the next question.

That only works if answering ten thousand of those questions a second is cheap, which is what the cache is for. Answers come from Redis, already prepared for the phase about to start, and the database stays off the hot path. The leaderboard that would have meant one database query per player per round becomes one query for the round.

• Plain HTTP polling against a server-driven state machine
• A phone browser and a QR code, with nothing to install
• Cache hit rate above 95%, which is what keeps the database off the hot path
• Server-rendered throughout, with no client-side framework

"Will it hold?" is a bad question to find out the answer to at nine in the evening on national television. So it was measured first. A load test drove 1,066,605 requests through the system with no failures, sustaining 2,959 requests a second at a median response of 108 milliseconds, with 98.4% of requests answered inside a second.

The tests that mattered most were aimed at the exact frightening moment a live quiz creates, which is everyone submitting at once. There is a thousand-way concurrent ranking test and a fifty-way simultaneous completion test. Every incident found in production became a permanent test, in a folder named after the bugs it exists to catch.

• 1,066,605 requests in a load test, with a 100% success rate
• 2,959 requests a second sustained, 108 ms median, 98.4% under one second
• Dedicated stress tests for simultaneous submission and ranking
• A built-in benchmark that extrapolated the CPU needed before launch