Design Cricinfo (Live Cricket Scoring)

The Problem

Your sports media company broadcasts live cricket scores to 10 million concurrent users during IPL and ICC tournaments. The current system uses a monolithic spreadsheet-style data model where a single "match" row tracks everything: runs, wickets, overs, player stats. Every ball bowled requires recalculating the entire match state from scratch. During peak matches, the scoreboard refresh takes 4 seconds, and commentators are typing into a separate system that frequently drifts out of sync with the score. Last month, a no-ball was recorded but the extra run was never added, and the wrong bowler was credited with a wicket because the system did not model ball-level granularity.

Cricket scoring is harder than most sports systems because the game has deeply nested structure. A match contains innings, innings contain overs, overs contain balls, and each ball can trigger multiple state changes: runs scored, wickets taken, extras awarded, striker rotation, bowling changes, and commentary generation. The system must handle all of this incrementally, without reprocessing the entire match history on every delivery.

Design the core classes for a live cricket scoring platform that handles match lifecycle management, innings and over tracking, ball-by-ball scoring with extras, scoreboard computation, player statistics, and live commentary with real-time observer notifications.

Requirements

Clarifying Questions

Before jumping into class design, ask questions to turn the vague prompt into a concrete specification. Cover four areas: core actions, error handling, boundaries, and future extensions.

You: "What match formats does the system support? Just T20 and ODI, or also Test matches with multiple innings per side?"

Interviewer: "Support all three: T20 (20 overs), ODI (50 overs), and Test (unlimited overs, two innings per side). The match format determines overs per innings and number of innings."

Three formats with different rules. T20 and ODI have a fixed over limit per innings, while Test matches have no over limit but allow two innings per side. This means the format should be configurable, not hardcoded. A good signal for encapsulating format rules behind an abstraction.

You: "How granular is the scoring? Do we track every single delivery, or just over-level summaries?"

Interviewer: "Ball-by-ball. Every delivery records runs scored, extras, wicket details, the batsman on strike, and the bowler. The scoreboard and player stats are computed from these individual ball records."

Ball-level granularity is the core of the design. Each Ball object is a rich event that drives scoreboard computation, player stats, and commentary. This is the atomic unit of the system.

You: "What types of extras exist, and how do they affect the over?"

Interviewer: "Wides and no-balls do not count as legal deliveries, so they do not advance the ball count within an over. Byes and leg-byes count as legal deliveries but runs are not credited to the batsman. All extras add to the team total."

Critical distinction: wides and no-balls mean the over gets additional deliveries. We need to track legal vs. illegal deliveries separately. The Over class must know when it is truly complete (6 legal deliveries bowled).

You: "How does the system handle wickets? What types of dismissals do we support?"

Interviewer: "Support bowled, caught, LBW, run out, stumped, and hit wicket. Each wicket records the dismissed batsman, the bowler who gets credit, and the fielder involved (for catches and run outs). A wicket on a no-ball is only valid if it is a run out."

Wicket types suggest an enum with associated data. The bowler-credit vs fielder-credit distinction is important for player statistics. The no-ball wicket rule is a domain constraint that validates ball state.

You: "What player statistics should the system compute live?"

Interviewer: "For batsmen: runs scored, balls faced, fours, sixes, strike rate. For bowlers: overs bowled, runs conceded, wickets taken, economy rate, maidens. These must update after every ball, not batch-computed."

Live stat computation means incremental updates. After each ball, we update the batsman's and bowler's running totals. This is much more efficient than recomputing from all balls.

You: "Should the system support live commentary and real-time notifications?"

Interviewer: "Yes. Auto-generate commentary text from ball events (e.g., 'FOUR! Kohli drives through covers'). Notify subscribers when milestones happen: wickets, boundaries, overs completed, century scored. The delivery mechanism is out of scope, but the event system must exist."

Observer pattern. The scoring engine fires events, and multiple listeners (commentary generator, scoreboard updater, notification service) react independently.

You: "How does match state management work? Can a match be paused for rain delays?"

Interviewer: "Matches move through defined states: SCHEDULED, TOSS, IN_PROGRESS, INNINGS_BREAK, COMPLETED, ABANDONED. Rain delays and bad light can move the match to a SUSPENDED state. Only valid transitions should be allowed."

State machine for match lifecycle. Invalid transitions (like going from COMPLETED back to IN_PROGRESS) must be rejected. The State pattern or a simple state machine fits here.

Final Requirements

Functional Requirements:

1. Create and manage cricket matches with configurable format (T20/ODI/Test)
2. Record ball-by-ball events with runs, extras (wide, no-ball, bye, leg-bye), and wickets
3. Track overs with correct legal delivery counting (wides and no-balls are extras, not legal balls)
4. Compute live scoreboard: total runs, wickets, overs bowled, run rate, required run rate
5. Compute live player statistics: batting (runs, balls faced, strike rate, fours, sixes) and bowling (overs, runs conceded, wickets, economy, maidens)
6. Generate commentary text from ball events and notify subscribers of milestones

Non-Functional Requirements:

1. Incremental state updates: each ball updates running totals without reprocessing the full history
2. Extensibility: new match formats, dismissal types, and stat computations can be added without modifying existing code
3. Thread safety for concurrent reads (scoreboard queries) during writes (ball recording)

Out of Scope:

• UI/rendering, persistence/database layer
• DLS method, powerplay rules, free hits (mentioned in Extensibility section)
• Player rankings, tournament/series management
• Video replays, DRS review system

Example Inputs and Outputs

Scenario 1: Normal delivery with runs

• Input: Record a ball in Match #1, Innings 1, Over 3. Batsman Kohli faces bowler Starc. 4 runs scored (boundary), no extras, no wicket.
• Expected: Ball is recorded. Kohli's batting stats update: +4 runs, +1 ball faced, +1 four. Starc's bowling stats update: +4 runs conceded, +1 ball bowled. Scoreboard shows updated total, run rate recalculated. Commentary generated: "FOUR! Kohli drives through covers off Starc."
• Why: Validates the happy path for ball recording, stat computation, and commentary generation.

Scenario 2: Wide ball with extra runs

• Input: Record a ball in Over 5. Bowler Anderson bowls a wide. 1 extra run (wide), plus batsmen run 2 additional byes.
• Expected: Ball is recorded as a wide. The over does NOT advance its legal delivery count. Anderson's bowling stats: +3 runs conceded (wide + 2 byes), ball count unchanged. Team extras increase by 3 (1 wide + 2 byes). Scoreboard total increases by 3. Commentary: "Wide from Anderson, batsmen scramble two more."
• Why: Validates extras handling, the critical distinction between legal and illegal deliveries, and correct bowling stat attribution.

Scenario 3: Wicket on a caught dismissal

• Input: Record a ball. Batsman Warner faces bowler Bumrah. 0 runs. Wicket: CAUGHT by fielder Kohli.
• Expected: Ball is recorded with wicket. Warner is dismissed, removed from batting. Bumrah's stats: +1 wicket, +1 ball bowled. Scoreboard: wickets +1. Next batsman comes in. Commentary: "OUT! Warner caught by Kohli off Bumrah. Warner departs for 35(28)."
• Why: Validates wicket processing, bowler wicket credit, fielder tracking, and batsman dismissal flow.

Try It Yourself

---

Step 1: Identify Core Entities

Start by asking: what are the main "things" in this problem? Look at the nouns in your requirements: match, team, player, innings, over, ball, scoreboard, commentary. Each of these has a distinct lifecycle and responsibility.

A common mistake is lumping everything into a flat "Match" class that tracks runs, wickets, overs, and player stats in giant hash maps. That approach is exactly the monolithic spreadsheet model we are replacing. Good design means each class has a single, clear job.

Notice that Ball is a value object (immutable after creation), while Over and Innings are mutable aggregates that grow as balls are added. Match orchestrates the lifecycle but does not compute stats directly. That separation is deliberate: computing stats is Scoreboard's job, and broadcasting events is the listener's job.

Step 2: Define Relationships and Class Design

Class Diagram

Deriving the Match Class

Match is the orchestrator: it owns state transitions, delegates ball recording to the current innings, and broadcasts events to listeners.

Deriving state from requirements:

This gives us the core state: format, state, innings, teams, listeners. The methods emerge from the actions: conductToss(), startInnings(), recordBall(), endMatch().

Deriving methods from needs:

Match State Machine

The match lifecycle is a state machine with well-defined transitions. This diagram is critical for your interview because interviewers love to probe invalid state transitions.