Practice/Meta/Design an Online Game Leaderboard

Design an Online Game Leaderboard

System DesignMust

Problem Statement

Design a platform that aggregates and displays live sports betting odds from multiple bookmakers, updating in real time as games progress and markets shift. The system must handle tens of thousands of concurrent sporting events across different leagues and sports, with odds changing every few seconds based on in-game events, betting volumes, and external news. Users expect to see the best available odds across all bookmakers instantly, along with historical trends and alerts when odds hit their target thresholds.

This system combines high-velocity data ingestion from dozens of external sources, real-time aggregation and comparison logic, and low-latency delivery to millions of users checking odds before placing bets. The platform must remain highly available during peak betting periods like major finals or championship games, where a single event can drive millions of concurrent users and thousands of odds updates per second.

Key Requirements

Functional

• Multi-bookmaker aggregation -- ingest live odds from 50+ bookmakers for the same event and market type
• Best odds discovery -- instantly show users the highest odds available across all sources for any bet
• Real-time updates -- reflect odds changes within 1-2 seconds of bookmaker updates during live games
• Price alert notifications -- notify users when odds for their watched bets reach specified thresholds
• Historical odds tracking -- display odds movement charts showing how prices changed over time for analysis

Non-Functional

• Scalability -- support 10M daily active users, 50K concurrent events, and 500K odds updates per second during peak
• Reliability -- maintain 99.9% uptime even when individual bookmaker feeds fail or lag
• Latency -- serve current best odds queries in under 100ms at p99, updates propagate within 2 seconds
• Consistency -- odds displayed must be accurate within the staleness window; stale data older than 5 seconds should be flagged

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Real-Time Data Ingestion Pipeline

The system must handle constant odds updates from dozens of external sources with varying protocols, reliability, and update frequencies. Interviewers want to see how you'll normalize heterogeneous feeds, handle backpressure when sources spike, and detect when a feed goes stale or offline.

Hints to consider:

• Use dedicated ingestion workers per bookmaker to isolate failures and apply source-specific rate limits
• Normalize incoming data into a canonical event and market schema immediately at ingestion boundaries
• Tag each odds record with source timestamp and ingestion timestamp to detect staleness and clock skew
• Consider a streaming platform like Kafka to buffer raw feeds and enable replay for debugging or backfill

2. Efficient Odds Comparison and Ranking

With hundreds of bookmakers offering odds on the same outcome, you need fast lookups to find the best price without scanning all sources on every query. Interviewers expect you to explain indexing strategies that support both point queries and range scans for nearby odds.

Hints to consider:

• Partition odds by event and market type so comparisons happen within small, hot datasets
• Maintain in-memory sorted structures per market to instantly retrieve the top-N best odds
• Use a cache layer with sub-millisecond read latency for the most frequently queried events and markets
• Debounce rapid updates from the same source to reduce write amplification to downstream stores

3. Handling Bursty Load During High-Profile Events

Traffic spikes 100x during major sporting events like World Cup finals or Super Bowl, with millions of users refreshing odds simultaneously. Interviewers want to see how you'll prevent hotspots, handle thundering herds, and maintain read latency under extreme load.

Hints to consider:

• Pre-warm caches for high-profile events hours before kickoff using predictive models or editorial flags
• Use request coalescing or batch fetching so concurrent requests for the same event share backend queries
• Implement tiered caching with CDN edge nodes for popular static content like historical charts
• Apply backpressure and graceful degradation by serving slightly stale cached odds if backend is overloaded

4. Price Alert and Notification System

Users set thresholds like "notify me when odds for Team A exceed 2.5x" and expect instant notifications when conditions are met. The challenge is evaluating millions of alert rules against every odds update without blocking the ingestion pipeline or creating notification storms.

Hints to consider:

• Store active alerts in a fast key-value store indexed by event and market for O(1) lookups during updates
• Use a separate async worker pool to evaluate alerts triggered by incoming odds changes
• Batch and deduplicate notifications to prevent spamming users if odds oscillate around their threshold
• Implement user-configurable rate limits and quiet hours to respect notification preferences

Suggested Approach

Step 1: Clarify Requirements

Start by confirming scale and scope with the interviewer. Ask how many bookmakers the platform integrates (50? 200?), how many concurrent events are typical (thousands? tens of thousands?), and what sports or markets are prioritized. Clarify whether the system needs to support live in-play betting where odds change every few seconds, or just pre-match markets with slower update rates. Confirm latency expectations for displaying updated odds and whether eventual consistency of a few seconds is acceptable. Ask if historical odds data must be queryable for analytics or just displayed as charts. Establish if the platform is read-heavy or if there's significant write load from user actions like setting alerts.