Design a Leaderboard

You finish a match in a mobile game and the screen says "You are now #48,213 this week, up 2,904 places", with the three players just above and below you. Another tab shows the top 10 in the world, updating as you watch.

Interviewers like it because the first answer, ORDER BY score DESC, works for a thousand players and fails for fifty million: a rank means counting everyone above you. It tests whether you know a structure that counts in O(log n), keep an in-memory board honest about durability, and can shard one global order. The steps follow A Framework for Any Design. Try each "Your turn" box before you read on.

#Clarify the problem

• Functional: record a match score; keep each player's best score on all-time, weekly and daily boards; show the top 10; show a player's rank and the 5 players above and below.
• Non-functional: a new score shows in rankings within about a second; reads in under 50 ms; no accepted score is ever lost; ties broken by who reached the score first; boards stay readable when a node fails.
• Out of scope: anti-cheat, friends-only boards (a follow-up), rewards for top players.

#Estimate the scale

• Score writes: 10 million × 10 = 100 million matches a day ÷ 86,400 ≈ 1,200 a second, about 5,800 at a 5x evening peak. Each one updates three boards: 3 × 5,800 = 17,400 board writes a second at peak.
• Reads: assume 3 leaderboard views per match: 300 million a day, about 3,500 a second, 17,000 at peak.
• Rank cost: in a balanced structure a lookup takes about log₂(50 million) ≈ 26 steps. Counting everyone above a player in a sorted list takes up to 50 million.

#Define the API

POST /scores                                game servers only (service credentials)
  body: { "match_id": "m_9f2", "player_id": 42, "score": 4200, "ended_at": "..." }
  200 { "best": { "all_time": 5100, "weekly": 4200, "daily": 4200 } }
  200 same body for a repeated match_id (no change)
 
GET  /boards/{board}/top?limit=10           board = all_time | weekly | daily
  200 { "entries": [ { "rank": 1, "player_id": 7, "score": 9930 }, ... ],
        "as_of": "2026-11-14T18:00:01Z" }
 
GET  /boards/{board}/players/{id}?around=5
  200 { "rank": 48213, "score": 4200, "above": [ ...5 ], "below": [ ...5 ] }
  404 the player has no score on this board yet

The decision worth arguing is who may write a score. If phones post their own scores, anyone with a proxy can claim 99,999. The game server, which ran the match, submits it with a match_id. That id also makes retries safe, which matters more once boards keep sums instead of bests.

#Model the data

-- source of truth: a database, partitioned by player_id
best_scores
  board_id     VARCHAR(24)    -- "all_time", "weekly:2026-W46", "daily:2026-11-14"
  player_id    BIGINT
  score        INT
  reached_at   TIMESTAMP      -- for ties: earlier wins
  updated_at   TIMESTAMP      -- indexed, for replays after a failover
  PRIMARY KEY (board_id, player_id)
 
matches_applied               -- each match counted once
  PRIMARY KEY (player_id, match_id)   -- same partition as the player's rows,
                                      -- so one local transaction covers both
 
-- ranking: one in-memory sorted set per board
weekly:2026-W46   member = player_id, sort key = score with tie-break (see deep dive)

The access patterns split cleanly. A score update writes one player's row: any database with a conditional update ("set 4200 if higher") works, partitioned by player. A rank is a query over everyone: SELECT COUNT(*) WHERE score > 4200 walks every higher entry in the index, up to 50 million. So rankings live in an in-memory sorted set, as found in stores such as Redis, which answers rank in O(log n). The database is the truth; the sorted set is a fast, rebuildable view of it.

#High-level design

The score service makes each score durable, then updates the in-memory boards that every read uses.

#Deep dives

#The sorted-set structure

A sorted set is two structures kept in step. A hash map from player to score answers "what is 42's score?" in O(1). An ordered index (a skip list or a balanced tree) keeps entries sorted by score. The trick that makes rank cheap: every link in the index also stores how many entries it jumps over. To find a rank, walk from the top and add up the jumps you take. You never visit the entries you skip.

A skip list is a sorted linked list with express lanes: level 0 links every entry; each higher level links a random subset, about half of the level below. Here is one with six players, highest score first. The number on each link is its span.

rank = 0; node = head; level = topwhile level >= 0:  while node.next[level] scores higher than target:    rank += node.span[level]; node = node.next[level]  level -= 1return rank + 1

Updating a score is "remove the old entry, insert the new one", each O(log n), fixing spans on the way. A balanced tree that stores subtree sizes gives the same costs; the skip list is popular because it is simple to make fast in memory.

#Sharding a sorted set

Say it first: 5 GB and 51,000 operations a second fit on one primary with read replicas. Shard when you outgrow that, at 10x or with hundreds of boards. Two schemes compete.

• Shard by player id (hash). Writes spread evenly. The top 10 is a merge: ask each of, say, 8 shards for its own top 10 and keep the best 10 of those 80. That is exact, because every global top-10 player is in their own shard's top 10. A player's rank is a scatter-gather: ask every shard "how many scores are higher than 4,200?" (O(log n) each) and add them up. Neighbours work the same way: ask each shard for its 5 entries just above and just below 4,200, merge, and keep the nearest 5 on each side.
• Shard by score range. Rank is easy: the count of all higher shards plus the rank inside your shard. But the shard with top scores is the hottest, ranges need rebalancing as scores grow, and a player crossing a boundary moves between shards.

Pick hashing by player. Its cost is 8 parallel calls per rank lookup, as slow as the slowest. The cached top 10 is merged once a second, not once a read.

#Durability of an in-memory board

An in-memory store can persist itself with an append-only log flushed every second, snapshots, and asynchronous replicas. Each can lose the last moment of writes: up to a second from the log, and whatever a promoted replica had not received.

The better answer is to stop needing the board to be durable. The database row is the truth and is written first. The sorted set is a view that can be repaired:

• After a failover, replay rows whose updated_at falls in the last few minutes. "Set if higher" is idempotent and order does not matter, so overlapping replays are safe.
• After losing everything, rebuild from the database. At an assumed 500,000 inserts a second, 50 million entries take 100 seconds. Serve the last cached top 10 meanwhile.
• If boards were sums of points, increments would not be idempotent. Apply each match once in the database (the matches_applied table) and write the database's new total into the set, never "add 300" to it.

#Daily and weekly boards, and ties

Each period is its own sorted set, with the period in its key: weekly:2026-W46. A new period starts empty because the key changes. When a period ends, copy its top results to the database and let the set expire. Two details:

• Which period does a late score belong to? Use the match's ended_at from the game server, not the arrival time, and keep the previous period open for a few minutes of grace before you declare final results.
• Whose period? Pick one clock, usually UTC, and say so. Per-region boards with local midnights are just more keys.

For ties, "earlier wins" must be in the sort key, or the order among equal scores is arbitrary. Pack it into one number: the score in the high bits and (2²⁰ − 1 − seconds into the week) in the low bits, so earlier means bigger. A week has 604,800 seconds, which fits in 20 bits (2²⁰ = 1,048,576), and scores up to a million also fit in 20 bits. Example: score 4,200 reached 190,800 seconds into the week gives 4,200 × 1,048,576 + (1,048,575 − 190,800) = 4,404,876,975. Forty bits in all, safely below the 53 bits a 64-bit float holds exactly, which matters because some sorted sets store scores as floats. For the all-time board, seconds since launch need about 30 bits for 34 years, so 50 bits in all.

If the product instead wants equal scores to share a rank ("joint 12th"), compute rank as "number of players with a strictly higher score, plus 1", which is a count by score range, not a position.

#Bottlenecks and failures

At 10x (58,000 matches a second at peak, about 514,000 sorted-set operations a second), one primary is not enough: shard by player into, say, 8 sets per board and cache the top 10. The database takes 58,000 conditional updates a second, partitioned by player. Most matches do not beat the player's best, so the database can skip unchanged rows and the sorted sets see fewer writes than matches.

#What a strong answer sounds like

#Follow-up questions

#How would you build a friends-only leaderboard?

Do not keep a sorted set per player. Look up the few hundred friends' scores in one batch and sort them on read; sorting a few hundred numbers takes microseconds.

#The top 10 must update live on screen. How?

Recompute it once a second and push it to viewers of that screen over server-sent events, or let them poll the cached copy. One computation serves everyone.

#How do you stop cheating?

Only game servers write scores, after validating the match. Scores far above a player's history are hidden from public boards until reviewed.

#Why not a heap for the top 10?

A heap gives the top k cheaply, but not anyone's rank, and updating an arbitrary player's score inside it needs extra bookkeeping. The sorted set answers all three questions with one structure.

#What if a score must be removed after a ban?

Delete the player's row and remove the member from each sorted set. Everyone below moves up by one automatically, because ranks are computed, not stored.