Design a live sports score search feature with near-real-time score updates
MicrosoftSoftware Engineer · OnsiteLast updated
A system design exercise for a sports app's search feature that returns matching games with live, continuously updating scores. It probes requirement precision such as an explicit update-delay target, relational versus NoSQL storage choices, live update delivery, and high availability during traffic spikes.
Design the search feature of a sports app that covers live games. A user types a team name, a league or a matchup, and the app returns the matching games. Each result shows the teams, the current score and the game status, and while a game is in progress the score on screen keeps updating without the user refreshing.
You are expected to set the requirements yourself and then defend them. The design discussion in this loop pushed on three points in particular: how the system stays highly available, whether a relational database or a NoSQL store fits the data (and, if you choose NoSQL, exactly why), and how precisely you pin down functional requirements, for example whether it is acceptable for a score change to take up to 2 seconds to reach the user.
Constraints and Clarifications
- Scores arrive from an upstream data feed; capturing them at the venue is out of scope.
- Traffic is very uneven: a few high-profile games can attract most of the concurrent viewers at once.
- No user or game counts are given; state your own estimates and design to them.
Clarifying Questions
- Which sports and leagues are in scope, and should search return only live games or also scheduled and finished ones?
- What delay is acceptable between a score change reaching us and the user seeing it: is up to 2 seconds fine, or is the target stricter?
- Should scores update live on the results list itself, or only after the user opens a game?
- What should a user see if the upstream feed goes quiet, or later corrects a score?
- Does search need autocomplete and tolerance for misspelled or nicknamed team names?
Hints
Hint 1
Two workloads, not one: Finding a game and keeping its score current change at very different rates and are read in very different ways; ask whether one store and one path should serve both.
Hint 2
Put a number on "live": Turn "real time" into an explicit delay target, then check what polling, pushing and caching each do to that target.
Follow-up questions
- A final draws ten times your normal concurrent audience into a single game. What saturates first, and how do you absorb it?
- The data provider sends a correction that lowers a score. How do you guarantee every client ends up showing the corrected value?
- How would you rank results by personal relevance, such as a user's favorite teams or location?
- How would you prove in production that the freshness target is actually being met?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.