System Design Problems
Design Leaderboard
Leaderboards are used in gaming, fitness apps, and competitive platforms. This design covers sorted data structures, real-time updates, and efficient rank queries for 100M+ users.
- Scale — 100M+ users, 1M score updates/second
- Latency — Rank query < 10ms
- Real-time — Score updates visible within 1 second
Leaderboards are deceptively simple: maintain a sorted set of scores and answer rank queries efficiently at scale.
Requirements Clarification
Functional Requirements
- Submit and update user scores
- Query user rank and score
- Query top-N users (global and friends)
- Query users around a given rank (neighborhood)
- Reset leaderboard periodically (daily/weekly)
- Anti-cheat score validation
Non-Functional Requirements
- Availability: 99.99% uptime
- Latency: Rank query < 10ms
- Consistency: Strong for score submissions
- Scale: 100M users, 1M updates/second
The core challenge is maintaining a sorted set under heavy write load. Naive sorting (O(n log n)) is too slow for 100M users. Redis Sorted Sets use skip lists for O(log n) operations.
Back-of-the-Envelope Estimation
Memory for Leaderboard
Here,
- =Number of users (100M)
- =8 bytes score + 8 bytes user_id
Redis Sorted Set Memory
Redis stores scores as 64-bit doubles (8 bytes) and member strings (variable). For 100M members: ~8 GB memory (with overhead).
This fits comfortably in a single Redis instance or small cluster.
High-Level Architecture
Redis Sorted Set Operations
DfSkip List Data Structure
Redis Sorted Sets use skip lists: a probabilistic balanced tree structure. Skip lists support O(log N) insert, delete, and rank operations. They are simpler to implement than balanced trees and perform well in practice.
Redis Leaderboard Commands
Here,
- =Add or update member score
- =Get rank (descending): O(log N)
- =Get top-N: O(log N + M)
Leaderboard Operations
# Update score
ZADD leaderboard 15000 "player:123"
# Get rank (0-indexed, highest first)
ZREVRANK leaderboard "player:123" // Returns 42
# Get top 10
ZREVRANGE leaderboard 0 9 WITHSCORES
# Get players around rank 42
ZREVRANGE leaderboard 37 47 WITHSCORES
Sharded Leaderboard
DfScore-Based Sharding
For 100M+ users, a single Redis instance may not suffice. Shard by score ranges: shard 1 holds ranks 1-1M, shard 2 holds 1M-2M, etc. Each shard is a separate Redis instance.
Shard Assignment
Here,
- =User's current rank
- =Users per shard (e.g., 1M)
Anti-Cheat: Score Validation
Leaderboards are targets for cheating. Validate scores server-side: (1) Check score is within achievable bounds, (2) Verify time-based progression (score can't jump too fast), (3) Cross-reference with game telemetry.
Data Model
Score Submission
Here,
- =Unique user identifier
- =Game or competition identifier
- =Game-specific validation data
Practice Exercises
- Design: How would you implement a "friends leaderboard" showing only the user's friends' ranks?
- Scale: Design a leaderboard that handles 10M score updates per second.
- History: How would you implement historical leaderboards (last 30 days) without consuming too much memory?
- Anti-cheat: Design a score validation system that catches 99% of cheaters with < 1% false positives.
Key Takeaways:
- Redis Sorted Sets with skip lists provide O(log N) rank operations
- Score-based sharding distributes load across multiple instances
- Anti-cheat validation must be server-side and time-aware
- Historical leaderboards use time-windowed aggregation
- Friend leaderboards require separate sorted sets per social graph
What to Learn Next
-> Design Twitter Real-time feeds and fan-out.
-> Design Instagram Social media at scale.
-> Caching Strategies Redis and distributed caching.
-> Back Pressure Managing write-heavy workloads.
-> Idempotency Handling duplicate score submissions.
-> Retry Patterns Resilient score submissions.