Design Gaming Leaderboard

Meta's "Design Gaming Leaderboard" interview question focuses on building a scalable, real-time system for ranking players by scores, often using Redis sorted sets (ZSETs) for efficient operations.[1][2]

Problem Statement

Design a real-time gaming leaderboard system that supports millions of players updating scores frequently while providing low-latency queries for global top rankings, a user's rank with nearby players, and friends' rankings. The system must handle high write throughput (e.g., score updates per second), read-heavy leaderboard views, and ensure data consistency without stale rankings.[5][7][1]

Functional Requirements

• Update player scores in real-time (e.g., after matches).
• Retrieve top-K players (e.g., top 10, 100).
• Get a player's current rank and surrounding players (e.g., rank ±50).
• Support per-game or global leaderboards.
• Display player metadata (name, avatar) alongside ranks.
• Handle friends/group leaderboards.[2][7][5]

Non-Functional Requirements

• Scale to 10M+ players, 10K+ score updates/sec, 100K+ queries/sec.
• Latency: <100ms for reads, <200ms for writes.
• High availability (99.99%), consistency for rankings.
• Use caching (Redis), backend services, WebSockets for real-time pushes, sharding for scale.[1][2][5]

Constraints and Scale

| Aspect | Constraint/Example | |--------|-------------------| | Players | Up to 10M unique users [1][2] | | Updates | 1K-10K score updates/sec peak [2][5] | | Queries | 50K-100K leaderboard views/sec [1][5] | | Score Range | 64-bit integers (e.g., points, ELO) [2] | | Leaderboard Size | Top 100 + user ±100 ranks [5][7] | | Data Retention | 30-90 days, then archive [2] |

Input/Output Examples

No formal LeetCode-style I/O exists, but typical API examples include:[2][5][1]

• Update Score: POST /leaderboard/{game_id}/update
  Input: { "user_id": "u123", "score": 1500 }
  Output: { "success": true, "new_rank": 42 }

• Top K: GET /leaderboard/{game_id}/top?k=10
  Output: [{ "user_id": "u456", "score": 2000, "rank": 1 }, ...]

• User Rank: GET /leaderboard/{game_id}/rank/{user_id}
  Output: { "rank": 42, "score": 1500, "nearby": [{ "user_id": "u789", "score": 1498, "rank": 43 }, ...] }

• Friends Leaderboard: GET /leaderboard/{game_id}/friends?user_id=u123
  Output: Sorted list of friends' ranks/scores.

Key Challenges and Solutions

• Ranking Efficiency: Use Redis ZSET (sorted set) with O(log N) add/rank ops via skip lists.[1][2]
• Sharding: Partition by score ranges or game_id for scale.[2]
• Real-time: WebSockets/pub-sub for updates; write-behind to DB.[5][1]
• Consistency: Atomic ZSET ops; eventual persistence to MySQL/Postgres.[2]