Live Scoring Systems: How They Work and Why They Break

Live scoring looks like the simplest part of a tournament platform. A number goes up, everyone sees it. In practice it’s where most sports platforms fail, and the failures are visible to every spectator at once.

We’ve built live scoring for cuesports championships, continental federations and national tournaments. Here’s how these systems actually work, and where they break.

The transport decision

Getting a score from the scorer’s device to a spectator’s phone is the first choice, and there are three realistic options.

Polling. The client asks the server “anything new?” every few seconds. Simple, works through every proxy and firewall, and trivial to debug. Its cost scales as viewers × frequency — 5,000 spectators polling every three seconds is 1,600 requests per second for data that changes maybe twice a minute. Fine for club events, wasteful at championship scale.

Server-sent events. The server holds an open connection and pushes when something changes. Cost scales with actual events rather than viewers × frequency, which matches sport: a snooker frame might have thirty scoring events in forty minutes. SSE is one-directional, which is exactly what spectators need, and it reconnects automatically in the browser.

WebSockets. Bidirectional and lowest-latency. Necessary when clients send data too — the scorer’s interface, or interactive features. Overkill for a read-only scoreboard, and more infrastructure to operate.

For most federation platforms, SSE for spectators and WebSockets for the scoring interface is the right split. Spectators only consume; scorers both send and receive.

Reconnection is the actual hard part

Whatever transport you pick, connections drop. Spectators are on stadium wifi and mobile data, moving between cells, locking their phones. The interesting question isn’t how you deliver an update — it’s what happens after a connection dies and comes back.

The failure that matters: a client reconnects and resumes listening for new events, having missed the three that happened while it was disconnected. The score now displays 14–8 forever while the actual match is at 21–8. Nothing errors. The user sees a number that looks live and isn’t.

Always re-fetch current state on reconnect, then resume the stream. The event stream is an optimisation for latency, not the source of truth. If your client can’t answer “what’s the score right now?” independently of the events it happened to receive, it will eventually show something wrong.

The second-order fix is a staleness indicator. If no update or heartbeat has arrived in N seconds, say so in the interface. “Reconnecting…” is honest. A confidently wrong score is worse than an obviously broken one.

Separate the display path from the record path

Spectators and the federation need different guarantees from the same data.

A spectator seeing a score half a second late is fine. The official result being wrong is not — it feeds rankings, selection, and prize money.

So treat them as two paths. The display path can be optimistic: show the update immediately, reconcile later if needed. The record path must be transactional, validated against the rules of the format, and reversible. Never let the fast path be the one that writes the official result.

This also solves corrections cleanly. A referee overturning a point means reversing a record-path write and letting downstream state — frame score, match result, standings — recalculate from rules. If your only representation of the score is an incrementing counter in a display cache, you can’t do that without manual repair.

The scorer’s interface decides your data quality

Everything above is wasted if the person at the table can’t keep up.

They’re often a volunteer, on a tablet, watching a live match, entering under time pressure. Every extra tap is a chance for the display to fall behind the play, and every ambiguous control is a chance for a wrong entry that someone has to correct later.

What works: large targets, sport-specific shortcuts rather than a generic number pad, undo that’s obvious and instant, and clear indication of what’s been saved versus what’s pending. What doesn’t: confirmation dialogs on every point, and interfaces that assume a stable connection.

If the scorer’s device goes offline mid-frame, they should be able to keep scoring locally and sync when it returns. Losing five minutes of scoring because the wifi dropped is a real failure mode at real venues.

Traffic arrives all at once

Live scoring load doesn’t ramp. It arrives when the match starts and vanishes when it ends, and the peak is the final — which is scheduled, published months ahead, and therefore predictable.

That predictability is a gift most systems don’t get. You can scale up deliberately before a known event rather than reacting to an alert. But it means designing so scaling is a setting rather than a migration, and knowing which parts of the page can be cached hard (schedules, profiles, completed matches) versus which genuinely can’t (the live score itself).

A useful pattern: serve everything except the live figures as static, cached content, and let only the score stream be dynamic. A championship page then costs almost nothing to serve to 5,000 people, because 95% of it is a static file and the remaining 5% is a small event stream.

What to test before an event

Load test at your real expected peak, not a comfortable number. If the final draws 5,000 concurrent viewers, test 5,000.

Then test the failure paths, because these are what actually go wrong:

• Kill the scorer’s connection mid-match and confirm they can keep working and sync
• Disconnect a spectator client for two minutes and confirm it shows the correct current score on reconnect, not a stale one
• Enter a wrong result three rounds deep and confirm the correction propagates through the bracket and standings
• Confirm the site still serves schedules and past results if the live scoring component is down entirely

That last one matters more than it sounds. Live scoring failing should degrade one feature, not take down the championship portal.

---

We build live scoring, tournament platforms and ranking systems for federations and championship organisers. If you’re planning one, tell us the sport and your event calendar, or see our approach to sports technology.