Engineering
Live Scoring at Scale: What Happens Between the Umpire's Tap and the Fan's Screen
A point is scored on court eight in a school gym with no signal. Two seconds later it is on a phone in another country. Here is the path it takes.
A rally ends on court eight. The umpire taps once. Somewhere between one and three seconds later, that point appears on a phone held by a grandparent watching from another country, on the tournament's public scoreboard, on the bracket that will advance when the match finishes, and in the dataset the analytics engine reads.
Described that way it sounds simple. The reason it is not is that court eight is in a school gymnasium with two bars of signal, the umpire is a volunteer who has used the app twice, and there are twenty-three other courts doing the same thing at the same time.
Rule one: the tablet must not need the network
The most consequential architectural decision in live scoring is what happens when connectivity fails, because at Indian tournament venues connectivity fails constantly. Gymnasiums are steel-framed boxes. Halls fill with several hundred people all on the same cell. The Wi-Fi that worked at setup on Friday is unusable by 10am Saturday.
So the scoring app is authoritative locally. A tap records the point, updates the on-screen state, applies the sport's rules — is that game point, does the serve change, has the set ended — and writes it to a local queue. All of that happens whether or not there is a network, in a few milliseconds, because it never asks anything over the wire.
The queue then drains to the server when it can, in strict order, with each event carrying its own sequence number and timestamp. A five-minute connectivity blackout produces a five-minute delay for spectators and precisely zero impact on the match. The umpire never sees a spinner, and the score is never wrong.
Rule two: never trust the client's arithmetic
The tablet computes the score so the umpire gets an instant response. The server recomputes it, from the raw event stream, using the same rule engine. If those two disagree, the server wins and the tablet is corrected.
This matters because clients drift. An app that has been open for six hours, backgrounded twice, and had one event delivered out of order can end up in a state that looks plausible and is wrong. Replaying the events server-side means the authoritative score is always a pure function of what actually happened, and that same replay is what lets an umpire correct a point from three rallies ago without anything downstream getting confused. The correction is just another event; everything after it is recomputed.
One event stream, many readers
Everything a spectator, a bracket, a broadcast overlay or an analytics model sees is derived from the same ordered event stream. That is why the bracket on the draws page and the score on the live page can never contradict each other — they are not two systems being synchronised, they are two projections of one log.
Rule three: the read path is where the traffic is
Twenty-four courts producing an event every thirty seconds is a trivial write load — roughly one write per second across an entire tournament. The read side is a completely different problem. A popular final can have thousands of people polling the same match simultaneously, and every one of them expects the number to be current.
Reads are served from a cache that the event stream invalidates on write, so a spectator's request almost never reaches the database. This is why a tournament's traffic profile is so lopsided and so manageable: the expensive thing is not the sport, it is the audience, and the audience is all asking for exactly the same few numbers.
Rule four: the umpire interface is the whole product
None of the above matters if the volunteer at courtside cannot use the app under pressure.
The scoring screen for each sport shows the smallest set of controls that sport needs and nothing else. Badminton is two large score buttons and a serve indicator. Wrestling needs point values, cautions and a fall. Basketball needs a clock. Building sport-specific interfaces instead of one configurable screen is more work and it is not close to negotiable — a generic interface means a volunteer hunting for the right control while a match waits.
- Targets sized for a thumb on a tablet held at an angle, in a hall with bad lighting.
- Undo that is one tap and always available, because the fix for a mistap has to be faster than the mistap.
- State that survives the app being killed, the tablet dying, or the umpire being changed mid-match.
- No modal dialogs during a rally. Ever.
What it adds up to
Roughly 73,000 matches have now run through this pipeline. The measure we care about is not throughput or latency — both are comfortable. It is that in that time, the number of matches where the published result had to be corrected because the system lost or mangled a score is the number an official record has to be able to claim: zero.
