System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. User Authentication: Allow users to create accounts, log in, and personalize their experience (e.g., selecting favorite teams or players).
2. Push Notifications: Enable users to receive real-time alerts for specific events, such as score changes, injuries, or significant plays.
3. Multi-Sport Support: Support for multiple sports with potentially different scoring systems, rules, and event types.
4. Historical Data Access: Users should be able to view past games, scores, and player statistics for reference.
5. Visualizations: Provide graphs or charts for player performance over time, trends, and game statistics to enhance user engagement.
6. Social Sharing Features: Allow users to share updates or results on social media platforms.
7. API Access: Facilitate third-party integrations via APIs for data scraping or embedding scores in other applications.

Non-Functional:

List non-functional requirements for the system...

Performance: The system must provide real-time updates efficiently without lagging, regardless of user volume.

Availability: The system should have minimal downtime to ensure users can continuously access live updates and player stats.

Partition Tolerance: The system should continue to function even if some components fail or become unreachable.

Scalability: The ability to efficiently scale horizontally to handle increased loads during peak usage periods.

Eventual Consistency: The system can allow for data updates to be delivered in an eventually consistent manner rather than requiring immediate consistency.

Capacity estimation

Estimate the scale of the system you are going to design...

Data Estimates

1. Average Write Size:
   • 80 bytes/write
2. Writes Per Minute:
   • 1,000 writes/min
3. Total Data Written Per Minute:
   • 80,000 bytes/min
4. Data Storage Over Time:
   • Per Hour: 4,800,000 bytes/hour (approx. 4.8 MB/hour)
   • Per Day: 115,200,000 bytes/day (approx. 115.2 MB/day)
   • Per Month: 3,456,000,000 bytes/month (approx. 3.46 GB/month)
   • Per Year: 42,048,000,000 bytes/year (approx. 42.04 GB/year)

Request Estimates

1. Daily Active Users (DAU):
   • 100K to 500K users
2. Read Requests:
   • 100K reads/min (average)
3. Write Requests:
   • 1K writes/min (peak)

Summary Overview

• Your system is estimated to handle around 80,000 bytes of write data per minute, translating to an annual total of approximately 42.04 GB.
• The request volume is estimated at 100K reads/min and 1K writes/min, driven by the user engagement around live events and statistical updates with 100K to 500K daily active users.

API design

Define what APIs are expected from the system...

All request would have to include an authorization header with the correct jwt token:

Updated API Endpoints with JWT Authentication

1. User Management
   • • POST /accountsDescription: Create a new user account.
     • Request Body: Account information (username, email, password, etc.).
     • Authentication: None needed.
2. User Authentication
   • • POST /accounts/loginDescription: Authenticate a user and return a JWT.
     • Request Body: Email and password.
3. Team Management
   • • POST /teams/favoriteDescription: Add a favorite team for the authenticated user.
     • Request Body: Team information (team_id).
     • Authentication: Required (send JWT in the header).
4. Game Management
   • • POST /gamesDescription: Create a new game.
     • Request Body: Game details (sport_id, team1_id, team2_id, start_time).
     • Authentication: Required (send JWT in the header).
5. Player Stats Retrieval
   • • GET /stats?player_id={player_id}Description: Retrieve stats for a specific player.
     • Authentication: Required (send JWT in the header).
6. Game Stats Retrieval
   • • GET /stats?game_id={game_id}Description: Retrieve stats associated with a specific game.
     • Authentication: Required (send JWT in the header).
7. Event Retrieval
   • • GET /events?game_id={game_id}&limit=10&offset=0Description: Retrieve all events that occurred during a specific game.
     • Authentication: Required (send JWT in the header).
8. Game Timeline Retrieval
   • • GET /timeline?game_id={game_id}Description: Retrieve a chronological timeline of game events.
     • Authentication: Required (send JWT in the header).

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Structured Data

1. Users
   • id (string, Primary Key)
   • username (string, unique)
   • email (string, unique)
   • password_hash (string)
   • favorite_teams (array of strings)
2. Sports
   • id (string, Primary Key)
   • name (string)
   • type (string) - e.g., team vs. individual sports
3. Games
   • id (string, Primary Key)
   • sport_id (string, Foreign Key referencing Sports)
   • team1_id (string, Foreign Key referencing Teams)
   • team2_id (string, Foreign Key referencing Teams)
   • start_time (datetime)
   • status (string) - e.g., ongoing, finished, scheduled
4. Players
   • id (string, Primary Key)
   • name (string)
   • team_id (string, Foreign Key referencing Teams)
   • position (string)

Unstructured Data

1. Stats
   • Player performance data (e.g., points scored, assists, etc.) could be logged in a flexible structure, possibly using JSON format:
2. { "player_id": "123", "game_id": "456", "stats": { "points": 20, "rebounds": 5, "assists": 8 }}
3. Events
   • Similar to stats, events could vary in structure depending on the type:
4. { "event_id": "789", "game_id": "456", "event_type": "score", "timestamp": "2023-09-20T12:00:00Z", "player_id": "123", "description": "Player 123 scored a 3-pointer"}

Indexing Strategy

1. Users Table (RDBMS)
   • Index on email:
     • Purpose: Fast lookup during user authentication and account management.
   • Index on username (if applicable):
     • Purpose: Accelerate searches if username searches are expected.
2. Sports Table (RDBMS)
   • Index on type:
     • Purpose: Efficient filtering and searching of sports by type (e.g., team sports, individual sports).
3. Games Table (RDBMS)
   • Index on sport_id:
     • Purpose: Enable quick joins and filtering of games associated with a specific sport.
   • Index on team1_id and team2_id (if applicable):
     • Purpose: Optimize lookup for games involving specific teams.
4. Players Table (RDBMS)
   • Index on team_id:
     • Purpose: Streamlines searches for players on a specific team, especially useful for team management interfaces.
   • Index on position:
     • Purpose: Enables efficient queries for players by their positions (e.g., forwards, defenders).

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

High-Level Flow Design

1. Receiving Game Updates from Sports Organizations
   • Pub/Sub Pattern: Sports organizations will push events (e.g., score updates, player stats) to your API.
   • API Gateway:
     • This layer serves as the entry point for all requests from sports organizations.
     • Example API Endpoint: POST /events to accept game updates.
2. Processing Events
   • Event Processing Service:
     • This service processes the incoming event data. It validates, logs, and routes the data.
     • This service can then publish the events to an internal message broker (e.g., Kafka, RabbitMQ).
   • Message Queue:
     • Stores and manages the distribution of events efficiently to prevent loss and ensure delivery.
3. Storing Event Data
   • Database Interaction:
     • Once processed, flow the data to the appropriate databases:
       • Relational Database for structured data (games, teams, players).
       • NoSQL Database for unstructured data (stats, events).
4. Publishing Events to Clients
   • Real-Time Notification Service:
     • This service subscribes to the relevant topics on the message queue to receive updates.
     • Clients (users) can connect via WebSockets to listen for real-time updates.
5. WebSocket Connection
   • WebSocket Server:
     • Maintains persistent connections with clients for real-time notifications.
     • When new events are received or stored, this server pushes updated data to connected clients.

Key Functions of the Timeline Service

1. Data Aggregation:
   • Collect and aggregate event data related to a specific game from both the relational and NoSQL databases.
   • Events to include can range from scoring plays, fouls, substitutions, and significant statistics.
2. Building Game Timelines:
   • Based on the aggregated data, the timeline service will format the information into a user-friendly timeline structure (e.g., chronological order with timestamps).
   • This service can utilize cached data for efficiency in serving timelines to users.
3. Query Handling:
   • Provide API endpoints to allow clients to fetch the timeline for a specific game.
   • Example API Endpoint: GET /timeline?game_id={game_id} to retrieve the timeline data.

Interaction Steps

1. Client Request:
   • Users (clients) request statistics for a specific player through the application interface.
2. Stats Service:
   • The stats service receives the request and begins processing it.
3. Data Retrieval:
   • The service queries the relational database to get structured player information (e.g., player name, team, position).
   • It queries the NoSQL database to retrieve unstructured event data related to the player's performance.
4. Data Aggregation:
   • The stats service processes and aggregates the player statistics, calculating totals and averages where applicable.
5. Response to Client:
   • The aggregated data, along with linked events, is formatted into a response that provides detailed insights about the player.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

1. Timeline Service with LRU Cache

LRU Cache Implementation

The LRU cache is ideal for storing timelines for the most popular games because it automatically removes the least recently accessed items when the cache reaches its capacity. This keeps frequently requested timelines readily available, optimizing performance.

• Cache Structure:
  • Key: game_id
  • Value: Timeline data structure for that particular game.

Interaction Flow

1. Client Request:
   • When a client requests the timeline for a game, the timeline service checks the LRU cache first.
2. Cache Hit:
   • If the timeline for the requested game is found in the cache, it is returned immediately to the client, minimizing latency.
3. Cache Miss:
   • If the timeline is not found, the service fetches the data from the NoSQL and RDBMS databases, builds the timeline, and stores it in the LRU cache for future requests.
4. Eviction Policy:
   • When the cache exceeds its capacity, the LRU cache evicts the least recently used timeline to make space for the new one.

Check Cache

Cache Hit

Cache Miss

Fetch Data from RDBMS

Store in Cache

Return Timeline

Client Request

LRU Cache

Return Timeline

Fetch Data from NoSQL

Build Timeline

Update LRU Cache

2. Real-Time Updates Using Server Push

WebSocket Server for Real-Time Updates

Using a server-push model via WebSockets allows the server to send updates to clients as events occur, maintaining a seamless and responsive user experience.

• Persistent Connections: Clients establish persistent WebSocket connections to the server upon loading the application or when significant events occur.
• Event Broadcasting: When a new event (like a score change) is processed by the event processing service, it will push those updates to all connected clients.

Interaction Flow

1. Client Connection:
   • The client initiates a WebSocket connection to the server, subscribing to updates for specific games or players.
2. Event Processing:
   • When a new event is received and processed (e.g., through the pub/sub model), the event processing service publishes the event to the message queue.
3. Broadcasting Events:
   • The real-time notification service listens to the message queue and pushes the event updates to all relevant clients.
4. Client Update:
   • Clients receive event notifications instantly, allowing them to update their UI without the need for individual polling requests.

Establish WebSocket

Process Event

Listen for Events

Push Updates

Deliver to

Client

WebSocket Server

Event Processing Service

Message Queue

Real-Time Notification Service

Benefits of This Design

1. Efficiency: By storing the most accessed timelines in a cache using LRU, you minimize database load and enhance response times for popular games.
2. Low Latency: The server push model reduces latency since clients receive updates immediately without polling, providing a more dynamic and responsive experience.
3. Scalability: Using WebSockets allows for handling multiple clients efficiently, as a single connection can manage multiple updates concurrently.
4. Resource Optimization: Clients only receive updates when there's an event, reducing unnecessary network traffic and load on both clients and the server.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Trade-offs and Considerations

1. Using NoSQL for Events and Stats:
   • Pros:
     • Flexibility: NoSQL databases are schema-less, which allows you to easily adapt to changing data structures without extensive migrations—an advantage when dealing with different stats formats for various sports.
     • High Write Throughput: NoSQL databases excel in handling high volumes of writes, making them suitable for real-time data generation where numerous events happen concurrently.
     • Scalability: They can scale horizontally more effectively than traditional relational databases, making them well-suited for growing datasets as you onboard new sports and stats.
   • Cons:
     • Eventual Consistency: Unlike relational databases that provide strong consistency, many NoSQL systems offer eventual consistency, which might lead to temporary discrepancies in data. This trade-off must be managed carefully, especially during high-stakes events.
     • Complex Queries: If you require complex queries and joins between events and stats frequently, a NoSQL solution may introduce complexity compared to standard SQL queries.
2. Adopting a Pub/Sub Model:
   • Pros:
     • Decoupling: The pub/sub architecture decouples producers (sports organizations) from consumers (your system components, clients), allowing each to scale independently and promoting a microservices architecture.
     • Improved Scalability: As the load increases with more events or subscribers, the architecture can adapt without significant redesigns. New clients can easily subscribe to relevant topics.
     • Message Reliability: Utilizing a message broker can introduce durability for events, meaning even if the system momentarily fails, events can be reprocessed upon recovery.
   • Cons:
     • Complexity in Management: Implementing pub/sub systems can add complexity regarding message delivery guarantees, monitoring, and ensuring that all components are correctly configured to handle real-time updates.
     • Latency Considerations: While the pub/sub model generally improves response times, assuming network performance is not optimal can introduce latency in message delivery and processing times, especially in high-load scenarios.

Summary of Trade-offs

By opting for NoSQL and a pub/sub model, you’ve made architectural choices that prioritize flexibility, performance, and scalability, which are essential in a real-time sports updating system. However, this comes with the necessity to balance consistency, potential complexity, and the management of event reliability.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Bottlenecks

1. Database Bottleneck:
   • Slow database queries causing delays in score updates or player stats.
2. Network Latency:
   • High latency in data transmission affecting real-time updates, especially for users in different geographical regions.
3. Server Overload:
   • Increase in traffic leading to overwhelmed servers, causing slowdowns or crashes.
4. API Rate Limits:
   • Exceeding rate limits set by third-party APIs resulting in failed data fetch requests.
5. Event Processing Delay:
   • Delays in processing real-time event notifications can lead to outdated information being presented to users.

Failure Scenarios

1. Database Outage:
   • The database server becomes unavailable, preventing access to score and player statistics.
2. Network Failure:
   • A network failure leading to complete disruption of data streaming and communication.
3. Single Point of Failure:

A key component (such as a central server or a microservice) fails without redundancy, leading to a total service outage.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

1. For databases:
   • Scale horizontally with replication.
   • Implement a health check mechanism for node failures.
2. For Read Bottlenecks:
   • Use read replicas and caching strategies to improve read throughput.
3. For Event Bus:
   • Ensure durability through persistent storage and acknowledge message consumption.
   • Use a high-availability setup to maintain uptime.