System Design FAQ: Top Questions

A Leaderboard System ranks users based on scores or metrics, used in gaming, fitness, learning, and productivity platforms. Key design considerations include efficient ranking, range queries, updates, and regional scoping.

📋 Functional Requirements

• Insert and update scores with rank recalculation
• Return top N, surrounding N (e.g. ±10), or specific user rank
• Global and region/country level boards
• Period reset (e.g. daily, weekly boards)

📦 Non-Functional Requirements

• Real-time updates under high concurrency
• Low-latency rank lookup
• Scalability for millions of users

🏗️ Core Components

• Write API: Submit/update score
• Read API: Get rank, top N, surrounding ranks
• Storage Engine: In-memory + persistent fallback
• Partitioning: Based on region, board type, or sharding

⚙️ Redis Sorted Set Example

ZADD leaderboard 2500 user:123
ZADD leaderboard 3800 user:789
ZREVRANK leaderboard user:123         # get rank
ZREVRANGE leaderboard 0 9 WITHSCORES  # top 10
        

🗄️ Fallback to Persistent Store (PostgreSQL)

CREATE TABLE scores (
  user_id TEXT,
  board_id TEXT,
  score INT,
  region TEXT,
  updated_at TIMESTAMP
);

CREATE INDEX idx_board_score ON scores(board_id, score DESC);
        

📦 Weekly Reset Strategy

• Snapshot scores every Sunday
• Move current leaderboard to leaderboard:prev:weekN
• Clear or reset base ZSET with ZREMRANGEBYRANK

🔀 Sharding Example

• Hash users to buckets: leaderboard:region:1, region:2 ...
• Query top-N across shards with merge-sort or fan-out

📈 Observability

• Writes/second and rank lookup latency
• Board reset stats, key size per region

🧰 Tools/Infra Used

• Cache/Ranking: Redis ZSETs, Aerospike
• Persistence: PostgreSQL, DynamoDB
• Queue: Kafka (for batch score ingestion)

📌 Final Insight

For high-speed leaderboards, use Redis ZSETs with periodic backups and partitioning. Balancing performance with freshness and accuracy across time-based boards is key to user engagement.