Bird
Raised Fist0

ESPNcricinfo System - Match, Innings, Ball, Scorecard, Commentary

LLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🎯
Design ESPNcricinfo System - Match, Innings, Ball, Scorecard, Commentary
40 min · medium
medium

Design a system to represent cricket matches with detailed ball-by-ball data, innings, scorecards, and live commentary updates.

Given Info
  • A Match consists of multiple Innings; each Innings consists of multiple Balls.
  • Scorecard aggregates runs, wickets, extras, and player stats per Innings and Match.
  • Commentary is updated live per Ball and must be thread-safe for concurrent updates.
  • Match status can be LIVE, COMPLETED, or UPCOMING and must be safely published across threads.
📋
Guided Steps
1/5
Step 1
Define core domain entities and their relationships
Design classes for Match, Innings, Ball, Scorecard, and Commentary. Specify relationships and ownership.
💡 Hint
Use composition for lifecycle ownership where contained objects cannot exist independently. Use inheritance or interfaces where behavior is shared.
Key Decision
abstract class Ball with instance state (runs, isWicket) because interface cannot hold fields in Java; Match aggregates Innings via composition (Innings lifecycle tied to Match).
Interviewer Expectation
Mid: Names composition and inheritance relationships. Senior: Explains why abstract class Ball holds state and interface cannot, and why Innings lifecycle depends on Match.
⚠️Common Wrong Answer
Using interface for Ball to hold runs and wicket info leads to inability to store instance state, forcing external state management and breaking encapsulation.
Step 2
Implement thread-safe live commentary updates
Design Commentary class to allow concurrent updates from multiple threads safely.
💡 Hint
Use volatile or synchronized to ensure visibility and atomicity of updates.
Key Decision
Use private final List<String> commentaryLines with synchronized addComment(String comment) method to atomically append commentary ensuring thread-safe mutation and visibility.
Interviewer Expectation
Mid: Identifies synchronized method for thread safety. Senior: Traces thread interleaving where without synchronized, two threads append simultaneously causing lost updates.
⚠️Common Wrong Answer
Using ArrayList without synchronization causes race conditions where commentary lines can be lost or corrupted due to concurrent modifications.
Step 3
Design Scorecard aggregation with concurrency in mind
Scorecard aggregates runs, wickets, extras per Innings and Match. Design methods to update and read stats safely.
💡 Hint
Use AtomicInteger or synchronized methods to handle concurrent updates from ball events.
Key Decision
Use AtomicInteger for runs, wickets, extras fields in Scorecard to allow lock-free thread-safe increments; read methods can be non-synchronized due to atomic visibility guarantees.
Interviewer Expectation
Mid: Names AtomicInteger usage for counters. Senior: Explains how AtomicInteger prevents lost increments in concurrent ball updates without blocking.
⚠️Common Wrong Answer
Using int fields without synchronization leads to lost updates when multiple threads increment runs or wickets concurrently.
Step 4
Represent Match status with safe publication
Match status changes from UPCOMING to LIVE to COMPLETED and must be visible across threads.
💡 Hint
Use enum for status and volatile field for safe publication.
Key Decision
Use volatile MatchStatus enum field in Match class to ensure visibility of status changes across threads without locking.
Interviewer Expectation
Mid: Uses enum for status. Senior: Explains how volatile ensures happens-before relationship so threads see latest status.
⚠️Common Wrong Answer
Using String for status without volatile causes stale reads where threads see outdated match status leading to inconsistent UI or logic.
Step 5
Extend system to support multiple formats without modifying existing classes
Design extensibility to add new match formats (e.g., T20, Test) without modifying Match or Innings classes.
💡 Hint
Use inheritance or strategy pattern with abstract classes or interfaces to follow Open-Closed Principle.
Key Decision
Use abstract class MatchFormat with concrete subclasses (TestFormat, T20Format) injected into Match via composition to extend behavior without modifying Match class, enforcing Open-Closed Principle.
Interviewer Expectation
Mid: Names Open-Closed Principle and use of abstract class. Senior: Explains how abstract class holds shared state and behavior, interface cannot, enabling extension without modification.
⚠️Common Wrong Answer
Hardcoding format logic inside Match class violates Open-Closed Principle and requires modifying Match for every new format.
🔌
API Design Challenge
Design APIs to fetch live match data including ball-by-ball updates, scorecards, and commentary with low latency and high concurrency.
Hints
  • Use WebSocket or Server-Sent Events for pushing live updates to clients.
  • Implement pagination or windowing for fetching historical ball data to reduce payload size.
  • Use caching layers and eventual consistency to balance load and freshness of live data.
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • abstract class Ball with instance state, not interface
  • composition relationship between Match and Innings with lifecycle ownership
  • synchronized method in Commentary for thread-safe updates
  • AtomicInteger usage in Scorecard for concurrent counters
  • volatile enum field for Match status visibility
Good to Have - 30%
  • Open-Closed Principle via abstract MatchFormat class
  • clear separation of domain entities with proper Java inheritance
  • explanation of thread interleaving causing race conditions without synchronization
Bonus - 10%
  • Use of immutable objects where applicable
  • detailed concurrency scenario tracing for commentary updates
Anti-patterns to Avoid
Using interface to hold instance state leads to poor encapsulation and forces external state management.
Using ArrayList without synchronization causes lost or corrupted commentary lines under concurrency.
Using int fields without synchronization or atomic wrappers causes lost increments in concurrent updates.
Using String for status without volatile causes stale reads and inconsistent state visibility.
Hardcoding format logic inside Match violates Open-Closed Principle and requires modifying core classes.
✅
Model Answer
▼ Reveal

The design models cricket matches with core entities Match, Innings, Ball, Scorecard, and Commentary. Ball is an abstract class holding instance state like runs and wicket info, as interfaces cannot hold fields in Java. Match composes Innings, owning their lifecycle. Commentary uses synchronized methods to ensure thread-safe live updates. Scorecard uses AtomicInteger fields for concurrent safe aggregation of runs and wickets. Match status is a volatile enum field to guarantee visibility across threads. Extensibility for match formats is achieved via an abstract MatchFormat class, adhering to the Open-Closed Principle by allowing new formats without modifying existing classes.

Key Decisions
  • Use abstract class Ball to hold runs and wicket state because Java interfaces cannot hold instance fields.
  • Use composition between Match and Innings to tie Innings lifecycle to Match lifecycle.
  • Use synchronized method addComment in Commentary to ensure atomic updates and visibility in concurrent environment.
  • Use AtomicInteger fields in Scorecard for runs, wickets, and extras to allow lock-free thread-safe increments.
  • Use volatile MatchStatus enum field in Match to ensure safe publication and visibility of status changes across threads.
  • Use abstract MatchFormat class with concrete subclasses injected into Match to extend match formats without modifying Match class, following Open-Closed Principle.
  • abstract class Ball holds runs, isWicket state because interface cannot hold instance fields in Java.
  • Match aggregates Innings via composition; Innings lifecycle tied to Match lifecycle.
  • Commentary uses synchronized addComment(String) to ensure atomic updates and visibility.
  • Scorecard uses AtomicInteger fields for runs, wickets, extras to allow lock-free thread-safe increments.
  • Match status is a volatile enum field to ensure safe publication and visibility across threads.
  • MatchFormat abstract class enables extension of match formats without modifying existing Match class, enforcing Open-Closed Principle.

Practice

(1/5)
1. In designing the Meeting Scheduler, should the Attendee entity be modeled as an abstract class or an interface, considering that attendees can be both internal employees and external guests with different data and behaviors?
easy
A. Interface, because it enforces a fixed implementation and prevents state duplication.
B. Interface, because attendees only define behaviors without shared state, allowing multiple inheritance.
C. Abstract class, because it allows sharing common state like name and email while enabling method overrides.
D. Abstract class, because interfaces cannot have any methods related to scheduling conflicts.

Solution

  1. Step 1: Analyze state and behavior needs

    Attendee has shared state (name, email) and some common behavior, which favors abstract class to avoid duplicating fields.

  2. Step 2: Evaluate interface limitations

    Interfaces cannot hold state, so using interface would force duplication or external state holders, complicating design.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Shared state + behavior -> abstract class [check]
Hint: Shared state? Use abstract class, not interface [check]
Common Mistakes:
2. You want to add a WeekendFeeStrategy to calculate parking fees differently on weekends using the current adapter-based design. What is the minimum change required to comply with SOLID principles?
medium
A. Add a boolean flag to Vehicle to indicate weekend and modify ParkingLot to check it.
B. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed without modifying existing classes.
C. Modify the existing FeeStrategy class to add weekend logic with if-else checks.
D. Add weekend fee logic inside the adapter class that adapts Vehicle to ParkingLot.

Solution

  1. Step 1: Identify SOLID principle involved

    Open-Closed Principle (OCP) requires extending behavior without modifying existing code.

  2. Step 2: Evaluate options

    Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it where needed without modifying existing classes. respects OCP by adding a new class implementing FeeStrategy. Add a boolean flag to Vehicle to indicate weekend and modify ParkingLot to check it. modifies Vehicle and ParkingLot, violating OCP. Options A and D modify existing classes.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    New strategy class extends behavior without modifying existing code [check]
Hint: OCP: extend with new class, don't modify existing ones [check]
Common Mistakes:
3. You want to add a WeekendFeeStrategy to the existing pricing module of the in-memory SQL database's query cost estimation. Which minimum change respects the Open-Closed Principle (OCP)?
medium
A. Modify the existing FeeCalculator class to add weekend logic inside the calculateFee() method.
B. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it without changing existing classes.
C. Add a boolean isWeekend flag to the FeeStrategy interface and implement conditional logic in all strategies.
D. Create a subclass WeekendFeeCalculator extending FeeCalculator and override calculateFee().

Solution

  1. Step 1: Understand OCP requirements

    OCP requires software entities to be open for extension but closed for modification.

  2. Step 2: Evaluate options against OCP

    Modify the existing FeeCalculator class to add weekend logic inside the calculateFee() method. modifies existing class, violating OCP. Create a new WeekendFeeStrategy class implementing FeeStrategy and inject it without changing existing classes. adds new strategy class without modifying existing code, respecting OCP. Add a boolean isWeekend flag to the FeeStrategy interface and implement conditional logic in all strategies. adds flag to interface, forcing all implementations to change, violating OCP. Create a subclass WeekendFeeCalculator extending FeeCalculator and override calculateFee(). subclasses but may require client changes, less flexible than strategy injection.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    New strategy class + injection -> OCP respected [check]
Hint: Add new strategy class, don't modify existing code [check]
Common Mistakes:
4. In LinkedIn's ConnectionManager, the method addConnection(User a, User b) checks if users are already connected before adding. Without synchronizing this method, what exact thread interleaving causes a double connection to be created?
medium
A. Thread 1 checks isConnected(a,b) -> false, context switch; Thread 2 checks isConnected(a,b) -> false; both add connections.
B. Thread 1 and Thread 2 both call addConnection simultaneously, but one fails due to a database constraint.
C. Thread 1 adds connection, then Thread 2 removes it before Thread 1 commits.
D. Thread 1 and Thread 2 both read connection list after addition, causing stale cache.

Solution

  1. Step 1: Identify the check-then-act race condition

    Without synchronization, both threads can see no existing connection and proceed to add, causing duplicates.

  2. Step 2: Trace exact thread interleaving

    Thread 1 calls isConnected(a,b) and gets false, then context switches before adding. Thread 2 also calls isConnected(a,b) and gets false, then both add connections concurrently.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Check-then-act gap causes double connection addition [check]
Hint: Check-then-act without sync -> double add race [check]
Common Mistakes:
5. The Workflow Engine must support ElectricCar vehicles requiring ChargingSpot compatibility. What is the minimum change to the current design to add this without modifying existing classes?
hard
A. Add charging logic inside Executor class to handle ElectricCar spots dynamically.
B. Modify Vehicle base class to include isElectric flag and add charging logic inside existing Spot classes.
C. Create a new ElectricVehicle interface and modify all existing Vehicle subclasses to implement it.
D. Add ELECTRIC_CAR to VehicleType enum, CHARGING to SpotType enum, create ElectricCar subclass, and update SpotCompatibility.COMPATIBILITY_MAP accordingly.

Solution

  1. Step 1: Identify extensibility requirements

    Adding ElectricCar and ChargingSpot must not modify existing classes to respect OCP and avoid class explosion.

  2. Step 2: Use enums and subclassing

    Adding new enum values and a new ElectricCar subclass extends functionality cleanly; updating compatibility map centralizes spot-vehicle matching without changing existing code.

  3. Step 3: Avoid modifying base classes or Executor

    Modifying Vehicle or Executor violates OCP and risks introducing bugs.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    New enums + subclass + compatibility map update -> minimal, no existing class change [check]
Hint: Add enums + subclass + map update, no existing class change [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard