Learn

Does every player on the leaderboard need to know their exact rank?

4 November 2026 · System design: one trade-off

You are designing the scores for an online game, and you have just said "a sorted set" for the leaderboard. The interviewer nods and adds one line: every player sees their rank on the results screen after each match. The structure you named is fine for the top of the board. The question is whether it still works for the player in the middle of it.

The requirement

After every match, the player sees a number: "you are 41,208th". Scores change all the time, many players finish a match in the same second, and the top hundred are shown to everyone on a separate page.

Two different promises hide in that sentence. The top hundred have to be exact, because people compare them and prizes may depend on them. The rank in the middle of the board is a number one person glances at. Whether it also has to be exact is the whole design, and it is worth asking before you draw anything.

Two designs and what each one costs

Option A: one ordered index of every player. A sorted set, or any balanced tree keyed by score, answers "how many players are above this score" in logarithmic time and gives an exact rank.

• What you get: one structure, exact answers, and the top hundred for free from the same index.
• What you pay: every score update in the game goes to one ordered structure on one node. Its memory grows with the number of players, and its write rate is the whole game's write rate. If you split it across machines, an exact rank means asking every shard and adding the answers on each read.

Option B: exact at the top, a range everywhere else. Keep a small exact index of the top hundred. For everyone else, keep a count of players per score bucket. A rank is the number of players in higher buckets, plus somewhere inside your own bucket.

WIDTH = 100  # points per bucket

class RankHistogram:
    def __init__(self, max_score):
        self.counts = [0] * (max_score // WIDTH + 1)

    def add(self, score):
        self.counts[score // WIDTH] += 1

    def move(self, old, new):
        self.counts[old // WIDTH] -= 1
        self.counts[new // WIDTH] += 1

    def rank_range(self, score):
        b = score // WIDTH
        above = sum(self.counts[b + 1:])
        return above + 1, above + self.counts[b]

Run it on five players scoring 950, 940, 720, 705 and 130, with a top score of 999. For 720 the answer is (3, 4): two players sit in higher buckets, and two share its bucket. The exact rank is 3. The player on 705 also gets (3, 4), and their exact rank is 4. Move the player on 130 up to 760 and both now get (3, 5).

• What you get: an update touches two counters, the counts add up across shards, and memory depends on the number of buckets, not players.
• What you pay: the rank is a range. It is wide exactly where players crowd, in the middle of the score distribution, and someone has to choose the bucket width and say what the screen shows.

What goes wrong, and the input that shows it

Option A fails quietly on the first busy evening: one node takes every write, and a slow rank query on it delays score updates for everyone. Option B fails in the product, not the servers. Two friends finish with 712 and 705 and both read "3rd to 4th". If the screen shows a single number taken from the range, one of them is told something false. The honest screens are a range, or a coarse band such as "in the top thousand".

What to say out loud

Ask first: "Who acts on the rank outside the top hundred, and does anyone care about a difference of a few places there?" Then commit: "If a prize or a ranking dispute depends on the middle of the board, I keep one exact index and pay for the write load, and I shard only when the numbers force it. If the middle rank is a number players glance at, I keep the top hundred exact and show everyone else a range from bucket counts."

The exercise

1. Pick a ranked list you know: a leaderboard, a seller ranking, the longest streaks in an app.
2. Write who looks at the top and who looks at the middle, and what each does with the number.
3. Write option A and option B for it in one line each, with what each stores.
4. Write the input that hurts each option: the busiest minute for A, two close scores in one crowded bucket for B.
5. Say the deciding question aloud, then your choice for two different answers to it, in under a minute.

Where this fits in Gadfly

System design is one of Gadfly's four rooms, next to algorithms, behavioral and code review. The design runs on a shared board, guided or as a mock, one trade-off at a time. In guided mode the tutor asks the next question, such as who reads the rank in the middle of the board, and does not draw the answer. In a mock it behaves like an interviewer, with no coaching during the round and a debrief at the end that quotes what was said, not a grade.