System Design FAQ: Top Questions

A Leaderboard System ranks users or teams in real-time based on score, activity, or metrics. It must support frequent updates, rank retrieval, and segment-based views (e.g., global, regional, friend groups).

📋 Functional Requirements

• Update user scores in real time
• Retrieve rank and nearby users
• Paginated views: top N, around me, friends
• Multiple leaderboards (e.g., game mode, region)

📦 Non-Functional Requirements

• Low latency score updates
• High write and read throughput
• Resilience to race conditions and loss

🏗️ Architecture Overview

• Clients: Game, app, or website submits score
• API Gateway: Validates, routes to scorer
• Score Engine: Applies score updates to store
• Leaderboard Store: Redis Sorted Sets or custom index

🧪 Redis ZSET Example

ZADD leaderboard:daily 990 "user123"
ZADD leaderboard:daily 1280 "user999"
ZREVRANK leaderboard:daily "user123"
ZRANGE leaderboard:daily 0 9 WITHSCORES
        

⚙️ Sample API Endpoint

// POST /leaderboard/update
{
  "user_id": "user123",
  "score": 990,
  "board": "daily"
}
        

🔁 Expiry Strategy

• Use TTL for time-bounded boards (daily, weekly)
• Keep archive of previous boards in cold storage (S3, RDS)

📈 Ranking Views

• Top N: ZREVRANGE start to end
• Near Me: ZRANK + offset range
• Friends: Filter ZRANGEBYSCORE from friend list

🔐 Security

• Server-side score validation
• Cheat prevention and audit logs

📈 Metrics

• Rank volatility per hour
• Score update volume
• Top percentile movement

🧰 Tools & Infra

• Store: Redis ZSET, DynamoDB with GSI, Elasticsearch
• Queue (optional): Kafka for delayed score normalization
• Webhooks: For trophy unlocks or milestones

📌 Final Insight

Leaderboards require low-latency stores like Redis and strict write patterns. Ensure atomic updates, TTL handling, and query diversity for a smooth experience across real-time and historical views.