A live keno draw produces one number set every few minutes and it's very straightforward; a random source picks the numbers, a server records them, done.
The genuinely hard engineering problem is everything that happens in the two or three seconds after, when that single result has to reach thousands of people scattered across a couple of thousand kilometres and land on every one of their screens at the same moment.
Get that wrong and instead of a mere rounding error, you have a fairness incident.
If a player in Brisbane sees the winning numbers even a few seconds before a player in Sydney, and bets are still open on one screen while they are closed on the other, you have accidentally built a time machine that lets some users act on information others do not have yet. So the whole system is designed around how everyone can see the same thing at the same instant, and if not, the product is broken.
When it comes to implementation, it is so much harder than it sounds.
How distance creates a latency problem
Start with physics, because its reasoning is always solid.
Brisbane to Sydney is roughly 750 kilometres of fibre, and light in glass is not instant. If we add the real routing path, which is never a straight line and you are looking at tens of milliseconds just in transit before any software does anything. Stack on the encoding delay of the live video feed, buffering on the player's device, and whatever the local network is doing, and the gap between the fastest and slowest viewer can stretch from milliseconds into whole seconds if nobody is managing it.
For a Netflix stream, a two-second spread between viewers is invisible and nobody cares. For a live draw with money riding on the timing, two seconds is a catastrophe. That single difference is the reason you cannot just throw the feed onto a standard video CDN and call it finished.
Using a server clock instead of the video feed
The smart move mainly unexpected by most people is that you do not try to make every screen update at the exact same wall-clock millisecond.
That is a losing battle against physics so instead you control what the user is allowed to do relative to the stream they are actually seeing.
The cleanest version of playing live keno from Queensland to New South Wales leans on this very idea. Betting closes based on a server-authoritative clock, not on whatever each player's video happens to be showing. The server is the single source of truth for when the round locks and every client obeys that signal regardless of where its video buffer sits. So even if your feed is running a second behind your neighbour two states away, your betting window closed at the same server moment theirs did. The video is just a view, actually the server decides reality.
That inversion is the whole trick. Once the authoritative event is the server clock rather than the pixels on screen the streaming delay stops being a fairness problem and becomes a pure user-experience one.
Patterns worth reusing
It is useful outside gaming because this pattern shows up anywhere correctness depends on timing across distance.
You separate the data channel from the media channel. The video rides one path, optimised for smoothness, and the authoritative game state rides a separate low-latency channel optimised for speed and ordering.
They are not the same stream and they do not have the same job. Treating "what the user sees" and "what is actually true" as two different problems is the move, and it generalises far past keno.
Live auctions, sports betting, trading interfaces, multiplayer anything, they all run into a version of this and solve it the same way.
You also lean on a server-authoritative model rather than trusting clients. Every client is assumed to be slightly wrong about the current state, because it always is, and the server reconciles them. If that sounds like how multiplayer games handle player position, it is exactly applied to a financial event instead of a character running across a map.
And you design for the slow client on purpose. The player on hotel wifi three states away is not an edge case to ignore, they are the case that decides whether your timing model actually holds. If your fairness guarantee only works when everyone has a fast connection, you do not have a fairness guarantee, you have a hope.
Where this applies outside gaming
Most real-time features people build are soft real-time.
A late notification or a laggy dashboard is not catastrophic just something annoying, so the timing model can be sloppy and nobody notices. A live draw across state lines is one of the few consumer products where the timing model is the product, and getting it wrong is immediately, visibly unfair to a paying user.
That makes it a genuinely good thing to take apart, even if you never go near gaming. The constraint forces a clean separation between truth and presentation that a lot of softer systems would benefit from copying.
Decide what your single source of truth is, make every client bow to it, and stop pretending you can beat the speed of light across a continent. You cannot, and can only make it stop mattering.
Top comments (0)