Case Studies
Gaming Leaderboard
Sharded sorted sets for real-time ranking, and why one global leaderboard becomes a write hotspot at scale.
Designing a real-time ranked leaderboard under constant score updates — a good vehicle for testing sorted-set reasoning specifically, and for spotting the exact point where "one Redis sorted set" stops being a complete answer and sharding-plus-merge becomes necessary.
What this lesson covers
Back ranking with Redis sorted sets, sharded by playerId hash instead of one global set, since a single key serializes every ZADD into a write hotspot. A top-k read fans ZREVRANGE out to every shard and merges the ranked lists; a player's exact rank costs one fan-out too.
- Score writes arrive at high sustained volume while top-k and 'what is my rank' reads must feel instant during active play.
- A sorted set is the well-known default; the real signal is noticing where a single sorted set stops being a complete answer.
- One global leaderboard becomes a write hotspot at scale, and fixing that changes how a top-k read has to be assembled.
- Computing one player's exact global rank without a full scan is the question a staff-level answer is ready for.
- Weigh sharding by player against region or game mode, which trades freshness for a cheaper merge on the global view.
Included in Plus and Pro
Continue reading “Gaming Leaderboard”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 17 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself