Design a Leaderboard
Redis Sorted Sets, Skip Lists, Sharding Strategies, and Real-Time Ranking at Scale
A leaderboard ranks players (or entities) by score in real time. The core data structure is Redis's Sorted Set (backed by a skip list + hash table), which provides O(log N) insertions and O(log N + K) range queries. Key challenges: sharding across Redis nodes when a single sorted set exceeds memory, handling millions of concurrent score updates, supporting Top-K queries with sub-ms latency, and choosing between real-time (every write updates rank) vs near-real-time (periodic batch aggregation) architectures. Used by gaming platforms, fitness apps, and competitive coding sites.
Redis Sorted Set Visualizer
Interact with a Redis Sorted Set. Add members with scores, query ranks, find members by score range, and increment scores. The set stays sorted by score automatically.
Score Update Throughput Calculator
Estimate the write throughput and infrastructure needed for your leaderboard based on player count and update frequency.
Sharding Strategy Comparison
When a single Redis sorted set can't hold all players, you need to shard. Each strategy has different trade-offs for global ranking queries.
Range-based vs Hash-based Sharding
- Shard by score range (0-1000, 1001-2000, ...)
- Top-K queries hit only top shard
- Hot shard problem for popular ranges
- Rebalancing needed as scores shift
- Shard by hash(user_id) % N
- Even distribution of writes
- Top-K requires scatter-gather across all shards
- Global rank needs merge sort
Hybrid Approach
- Top 1000 in a single "hot" sorted set
- Remaining players hash-sharded
- Promotion/demotion between tiers
- Most queries hit the hot set
- Hash-shard all writes for throughput
- Background job merges top-K from each shard
- Global leaderboard updated every N seconds
- Near-real-time but highly scalable
Top-K Query: Skip List Traversal
Redis sorted sets use a skip list internally. ZREVRANGE (top-K) starts at the tail and walks backward. Multi-level forward pointers enable O(log N) access to any position, then O(K) to collect K results.
Real-Time vs Near-Real-Time
Toggle between architectures to compare latency, consistency, and cost trade-offs.
Real-Time Architecture
Comparison
Architecture
Key Design Decisions
Score Storage Model
Store scores in Redis sorted sets with ZADD key score member. Use ZINCRBY for additive scoring (accumulate points) or ZADD with the GT flag for high-score tracking (only update if new score is higher). Back up to a persistent database (PostgreSQL/DynamoDB) for durability.
Tie-Breaking
Redis sorted sets break ties by lexicographic order of the member name. For custom tie-breaking (e.g., earlier submission wins), encode a timestamp in the score: score = points * 1e10 + (MAX_TS - timestamp). This gives higher rank to earlier submissions at the same point level.
Anti-Cheat & Validation
Never trust client-submitted scores. Use a score processor that validates against game state, applies rate limits, and flags anomalies. Server-authoritative scoring: the game server computes and submits scores, not the client. Add replay verification for critical competitions.
Relative Ranking
"What's my rank?" uses ZREVRANK key member in O(log N). For "show me neighbors" (players ranked around me), use ZREVRANGE key rank-5 rank+5. These operations are fast even with millions of members, making Redis ideal for both absolute and relative leaderboards.
Capacity Estimation
Size your Redis cluster for the leaderboard.