Art of Codeartofcode
Lesson 3 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)

35.2 How big is this, really?

3 min read+10 XP

Step 2: Estimates (5 minutes)

Assume about 100 bytes per member in a sorted set, a popular player picked by ~66% of teams, about 100,000 sorted-set updates a second per shard, and users refreshing every ~10 seconds during peak.

WhatWorkingResult
Membersgiven20 million teams
Memory for one leaderboard20 million × 100 bytes≈ 2 GB: fits one Redis node, but busy
Scores changed by one six from a popular player20 million × 0.66≈ 13 million
Time to apply on one shard13.2 million ÷ 100,000 a second≈ 132 s: longer than the gap between balls
On 20 shards13.2 million ÷ 2 million a second≈ 7 s
Read trafficsay 5 million users watching ÷ 10 s≈ 500,000 reads a second at peak

What the numbers say, out loud:

  • "Memory is fine; write bursts are not. Per-ball updates on one node can't keep up, so we batch and shard."
  • "Reads are huge, but most are the same top 100. Cache that; 'my rank' is the only per-user read."
  • "Exact final ranks are a separate, slower job at the end, not something the live system must guarantee every second."

Interviewer pushback:

  • "Why not recompute every team's score from scratch every few seconds?" → 20 million teams × 11 players is cheap arithmetic in a batch; the expensive part is writing them into the ranked structure. Rescoring only affected teams, once per batch, keeps writes down.

Memory code: "One ball, millions of writes: batch them and spread them."