Design a live sports score search feature with near-real-time score updates

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. ```hint 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 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. ``` ### 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? ### What a Strong Answer Covers - Requirements stated precisely, including a measurable freshness target and what happens when it is missed - A data model and API that separate slowly changing searchable data from fast-changing score state - A storage choice for each kind of data, with the relational-versus-NoSQL trade-offs argued from access patterns - A live-update delivery path (push or poll) with capacity reasoning for the most-watched games - High availability: redundancy, failover and graceful degradation when the feed, a store or the search index fails - Correct handling of duplicate, out-of-order and corrected score events ### 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?