Art of Codeartofcode
Lesson 13 of 15

35. Design a Leaderboard (Top-K)

1
The interview prompt
2
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 yourself
13
Variations to practise
14
Sources
15
Code lab
35. Design a Leaderboard (Top-K)

Variations to practise

3 min read+10 XP

Chapters used

Approach (1), Estimation (2), Caching (12, 13), Sharding (15), Probabilistic data structures and top-K (20), Message queues (22), Real-time updates (21), Failures (29).

Try these variations

Each is a common follow-up. Answer in two minutes, then check the sketch.

  1. "Show a friends' leaderboard." → Look up each friend's score (one ZSCORE each, or a small cached set per user) and sort the few hundred locally.
  2. "A global all-time leaderboard for a game." → Updates are per user action (not fan-out), so update immediately; shard by user, cache the top, use percentiles for most users.
  3. "Weekly leaderboard that resets." → One sorted set per week (lb:2026-w41), with a TTL after the week ends; archive the final top results.
  4. "Prevent cheating." → Scores come only from server-side events, never from the client; anomaly detection on impossible scores; the final job is the source of truth.