CricInfo

Live Cricket Score Platform

Design the scoring core of a live cricket site: a scorer enters each ball, the system applies the Laws (extras, overs, strike, dismissals), keeps the scorecard, supports corrections, and pushes updates to viewers.

Overview

A live cricket site shows a scorecard that changes with every ball. Behind it, an official scorer enters each delivery: who bowled it, how many runs were made, whether it was a wide or a no ball, and whether a batter was out. The system must turn that stream of balls into the score, each batter's runs and balls, each bowler's figures, whose turn it is to face, and the result.

The problem tests three things. First, domain modeling: cricket has rules that change the count in awkward ways (a wide adds a run but is not one of the six balls of an over), and your classes must hold them in one place. Second, a source of truth: if the ball log is the truth and every figure is derived from it, a scorer's correction is simply 'remove the last ball and replay'. Third, the read side: one scorer writes, and very many viewers read, so updates are pushed to subscribers rather than recomputed per viewer.

A strong answer says 'the ball log is the truth' early, puts format rules (overs per innings, overs per bowler) in data, validates each ball against the Laws, and shows a correction in a test.

Scoping the problem

Which formats? — Limits differ — T20 and one-day in the core; Test as a follow-up
Which extras? — Each changes the count differently — Wide, no ball, bye, leg bye
Which dismissals? — Some are not allowed off a wide or a no ball — Bowled, caught, lbw, stumped, hit wicket, run out
Can the scorer correct a ball? — Decides whether state is stored or derived — Yes: undo the last ball
How many writers per match? — Decides the lock — One scorer; many readers
How do viewers get updates? — Push or poll — Push a snapshot after each ball
Career statistics, commentary, tournaments? — Separate read models — Follow-ups

The Laws the code applies

Every rule below is enforced or computed in the implementation. They come from the MCC Laws of Cricket and the ICC playing conditions.

An over is 6 balls, bowled from each end in turn — MCC Law 17 — legal % 6 == 0 ends the over and swaps the strike
A bowler may not bowl two overs in a row — MCC Law 17 — check compares with last_over_bowler
A wide: one run penalty plus any runs, scored as wides, not one of the over, all debited to the bowler — MCC Law 22 — Adds to extras and to the bowler; legal does not move
A no ball: one run penalty (a no ball extra), not one of the over; runs off the bat go to the striker — MCC Law 21 — Penalty to extras, bat runs to the striker, both to the bowler
Byes and leg byes go to the batting side, not against the bowler — MCC Law 23 — Adds to extras only
Off a wide, only hit wicket, obstructing, run out or stumped; off a no ball, only hit the ball twice, obstructing or run out — MCC Laws 21 and 22 — ALLOWED_OUT refuses anything else (the code models run out, stumped, hit wicket)
Batters return to their original ends when a boundary is scored (unless it came from an overthrow) — MCC Law 18.11.2 — Boundaries are entered as runs (4 or 6), which are even, so the strike does not change
When the striker is bowled, caught, lbw, stumped or out hit wicket, the not out batter returns to their original end — MCC Law 18.11.1 — The incoming batter takes the dismissed striker's place, on strike
After a run out, the not out batter goes back to the end they left only if they had not already crossed — MCC Law 18.12.1 — crossed=True on a run out swaps the ends first; the new batter fills the dismissed batter's end
T20I: 20 overs an innings, at most 4 per bowler; ODI: 50 and 10 — ICC playing conditions — Format records
A Test is two innings for each side — ICC Test playing conditions — Out of scope for the demo

One figure is a scorers' convention, not a Law: a batter's balls faced count every ball except a wide (a no ball counts). The code follows it.

One ball, from scorer to viewers

The demo uses a tiny format (2 overs an innings, 1 per bowler, 3 players a side) so the whole match fits in a table. Reds bat first; r1 and r2 open.

0.1 — 1 run — 1/0 — Odd runs: r2 now on strike
0.2 — 4 — 5/0 — To r2
wide — wide, no runs — 6/0 — One run penalty; not one of the over
no ball — no ball, 2 off the bat — 9/0 — 1 penalty plus 2 to r2; not one of the over
0.3 — bowled — 9/1 — r3 comes in on strike
0.4 — 1 leg bye — 10/1 — An extra, not the bowler's; odd runs: r1 on strike
0.5 — 6 — 16/1 — To r1
0.6 — 0 — 16/1 — Over ends; ends swap, r3 on strike
1.1 — 3 by b2, then undo — 19/1, then 16/1 — Correction: remove the ball and replay the log
1.1 — caught — 16/2 — No batters left: innings over, target 17

After the first over, bowler b1's figures are 6 balls, 15 runs, 1 wicket: every run except the leg bye. The chase then scores 4, 6, a bye and 6 to reach 17/0 in 0.4 overs, and the result is 'Blues won by 2 wickets'.

What you will be able to do

Scope a live scoring system and list the Laws your code must apply.
Model the ball log as the source of truth and derive the scorecard by replaying it.
Handle wides, no balls, byes and leg byes correctly for the team, the batter and the bowler.
Support a scorer's correction with undo and replay, and say what it costs.
Push consistent snapshots to many viewers without letting them slow the scorer.

Functional requirements

Formats as data: overs per innings and the most overs one bowler may bowl (T20I 20 and 4; ODI 50 and 10)
record(delivery): bowler, runs, extra (wide, no ball, bye, leg bye) and an optional dismissal
Validate each ball: innings not over, no consecutive overs, bowler quota, same bowler within an over, dismissal allowed for that extra
Keep the scorecard: total, wickets, overs, extras, each batter's runs and balls, each bowler's balls, runs and wickets
Rotate the strike on odd runs and at the end of each over; bring in the next batter after a wicket
End an innings when all out, overs are used up, or the target is reached; set the result
undo() removes the last ball; subscribers receive a snapshot after every change

Non-functional requirements

The ball log is the only stored state; every figure is derived, so a correction can never leave figures out of step
One lock per match makes record and read atomic: a reader never sees half a ball
Subscribers are called outside the lock with a snapshot, so a slow viewer cannot block the scorer
A new format is a new Format record; no scoring code changes
Recording a ball is O(1); undo replays the innings, O(balls)

Interview questions

The scorer entered a 3 that was really a 2. How do you correct it?
How do millions of viewers get the score without overloading the server?
How would you add Test matches?
How do you compute career statistics across matches?
Two scorers or a scorer and an admin tool write at once. What breaks?