Katkat
Back

Find Nearby High Scores in a Large Game Leaderboard

MetaSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

Design a high-scale gaming leaderboard service capable of real-time score updates, deterministic tie-breaking, friend-filtered leaderboards, and efficient "nearby competitor" queries under extreme write loads.

Scenario

Design the backend infrastructure for a global mobile and cloud gaming platform that tracks player achievements across thousands of games. A central feature is the dynamic leaderboard, where players can view their absolute rank, see players immediately above and below them ("surrounding players"), and toggle between a global view and a friends-only view.

Requirements

Functional Requirements

  • Score Submission: Update or record a player's personal best (high score) for a specific game.
  • Nearby Competitor Query: Given a player_id, return the player's exact rank along with the k players ranked immediately above and k players ranked immediately below them.
  • Deterministic Tie-Breaking: If two or more players have the identical score, resolve ties deterministically (e.g., the player who achieved the score first ranks higher; secondary tie-break by player_id).
  • Friend Filtering: Allow players to view the leaderboard filtered exclusively to their social graph / accepted friends.

Non-Functional Requirements & Scale

  • Scale: 100 million Daily Active Users (DAU) across 10,000 games.
  • Throughput:
    • Global peak writes: 100,000 score submissions per second.
    • Hot game: A viral game can receive up to 40,000 writes/sec and 100,000 reads/sec.
    • Global peak reads: 250,000 requests per second.
  • Latency: p99 latency < 50ms for nearby queries and top-N reads.
  • Consistency: Eventual consistency is acceptable within 1–2 seconds, but a player's own submitted high score must never regress.

What Your Design Should Cover

  1. API Design: Endpoints for score submissions, querying neighboring ranks, and friend-filtered rankings.
  2. Data Model & In-Memory Indexes: Data structures suitable for fast rank calculation and range retrieval (e.g., Redis Sorted Sets, Skip Lists, distributed segment trees).
  3. Tie-Breaking Strategy: Encoding secondary attributes into score systems without exceeding precision limits.
  4. Hot-Game Partitioning: Strategies to scale a single game whose traffic exceeds the throughput and memory of a single node.
  5. Social Leaderboard Architecture: Trade-offs between fan-out-on-read vs. fan-out-on-write for friend rankings.

Hints

Hint 1

To handle deterministic tie-breaking without multi-field indexing, evaluate encoding the score and the inverted timestamp into a single composite value.

Hint 2

For massive hot games, consider sharding leaderboards by score ranges (score bucketing) or maintaining hierarchical rank-count trees rather than relying on a single Redis sorted set.

Hint 3

For friend-specific leaderboards, examine whether fetching high scores directly for a player's friends list on demand is more cost-effective than materializing per-friend feed structures.

Follow-up questions

  • How do you handle tie-breaking when the combined score and timestamp bits exceed the 53-bit integer limit of double-precision floats used in standard Redis sorted sets?
  • If a game imposes a hard score cap (e.g., 9,999 points) where millions of players share the exact same score, how do you prevent hotspots and maintain efficient neighbor pagination?
  • How would your architecture support periodic (weekly or seasonal) leaderboard resets without causing severe write stampedes and cache invalidation spikes?