35. Design a Leaderboard (Top-K)
1
The interview prompt2
35.1 What do you ask first?3
35.2 How big is this, really?4
35.3 What are the doors?5
35.4 What do we store?6
35.5 What does the whole system look like?7
35.6 How do sorted sets work for this?8
35.7 How do you handle real-time updates?9
35.8 How do you handle ties?10
35.9 How do you shard a leaderboard?11
35.10 What would you say in the last five minutes?12
Score yourself13
Variations to practise14
Sources15
Code lab35. Design a Leaderboard (Top-K)
35.9 How do you shard a leaderboard?
3 min read+10 XP
One sorted set of 20 million fits in memory, but the write bursts and read traffic need more than one node. Options:
Figure: by user, every shard contributes to rank; by score range, the top shard gets hot.
- Shard by team ID (hash): even load. Top 100 = take each shard's top 100 and merge; my rank = sum of
ZCOUNTabove my score across all shards (one call per shard, done in parallel). In the chapter's code, with 8 shards, the merged top 10 and the summed rank match the single sorted set exactly. - Shard by score range (0-100 points on shard 1, 100-200 on shard 2 ...): rank is mostly local, but the top shard gets the most attention, and teams move between shards as scores change, which makes updates more complex.
- Approximate rank: keep a histogram of scores in buckets; "you're in the top 12%" needs only the bucket counts, no per-shard calls. In the chapter's code, the approximate percentile is within a few points of the exact one. Many apps show exact rank for the top few thousand and a percentile for everyone else.
Our pick: shard by team ID across ~20 shards, cache the merged top 100 each batch, fan out "my rank" to all shards in parallel (and cache each user's rank until the next batch), with percentiles as a cheaper fallback under extreme load.
Memory code: "Shard by team, merge the tops, sum the counts above me."