Design Top-K Leaderboard

Take a competitive mobile game with 80 million players who have ever finished a ranked match. After every match the player sees their new score and global rank, and can open boards for the whole world, their country, this week and their friends. A season lasts eight weeks, after which seasonal boards reset and the old standings are archived for rewards.

Behind the screen are three different kinds of question. Top N: who are the best hundred players? Rank of one player: where exactly do I stand among 80 million? Neighbourhood: who is just above and just below me? The first is the same for everyone and caches well. The second and third are personal, and a database index does them badly.

Assume 30 million daily players who each finish about 25 ranked matches a day, and who look at a leaderboard about 40 times a day. Peaks come at the end of weekly events, about five times the average.

Writes and reads take separate paths, a CQRS shape. On the write path, game servers report each match to the score service. It rejects results that fail anti-cheat checks, applies each player's rating change to the score store in one transaction keyed by match id, so a repeated report changes nothing, and appends the new absolute ratings to a partitioned score log. The score store is the durable record; everything downstream can be rebuilt from it.

Ranking workers consume the log and write each player's new rating into every board that player belongs to. Because the log carries absolute values, not deltas, applying the same event twice gives the same result, and a worker that crashes and replays a few seconds of events does no harm.

On the read path, the top of each board is served from an edge cache refreshed every second. Rank and neighbourhood queries go to the query API, which reads from Redis replicas for most requests and from the primary when a player has just finished a match and must see their own update. Friends boards fetch the friend list and look up scores in bulk.

A skip list is a sorted linked list with express lanes. Every element sits on the bottom level; about half also appear on the level above, a quarter on the level above that, and so on. A search starts on the top lane, moves right while the next element is still smaller than the target, then drops a level. It reaches any element in about log n steps, and inserts only need to fix the pointers along that path.

Redis sorted sets add one field to every forward pointer: its span, meaning how many bottom-level elements that pointer jumps over. While searching for a member, add up the spans of every pointer you follow. When you arrive, the total is the member's position. Inserts and deletes adjust spans on the same path they already touch, so the cost stays logarithmic. That is how ZREVRANK on 80 million entries returns in microseconds.

A sorted set pairs that skip list with a hash table from member to score. Looking up a player's current score is a hash lookup; updating it removes the old node and inserts a new one. Range commands such as ZREVRANGE walk forward from a position found by rank, which is exactly what "five above and five below me" needs.

Ratings cluster heavily. Tens of thousands of players can share the same rating, and Redis then orders them by member id, which is arbitrary and feels unfair. The usual product rule is that whoever reached the score first ranks higher. You can encode that inside the sorted set score itself: packed = rating x 2^32 + (2^32 - 1 - seconds_since_season_start). Higher rating always wins; for equal ratings, the earlier time leaves a larger remainder and ranks higher.

Mind the arithmetic. Sorted set scores are 64-bit floats with 53 bits of exact integer precision. Spending 32 bits on time leaves 21 bits for the rating, so ratings must stay below about two million. That is plenty for a rating system, but a game with huge point totals should use coarser time, such as minutes, or keep ties in a secondary structure. Silent rounding here produces wrong ranks that nobody notices until a prize dispute.

One shard is fine at 45,000 updates a second. Suppose the game grows fivefold, or adds a global event where everyone plays at once. You have three options.

Split by score range. Shard one holds ratings above 3,000, shard two holds 2,000 to 3,000, and so on. Rank is the count of players in all higher shards plus your rank inside your own shard. Top N reads one shard. The weakness is balance: ratings are not uniform, the boundaries need to move as the distribution shifts, and a player crossing a boundary needs a delete on one shard and an insert on another.

Split by player hash. Writes spread evenly across, say, eight shards. Top N becomes a merge of each shard's top N, which is cheap. Exact rank needs ZCOUNT of scores above yours on every shard and a sum, which is eight small calls in parallel, and each still logarithmic.

Tiered. Keep an exact sorted set only for the top tier, for example the best 200,000 players, which is where rank actually matters to people. Everyone else gets a percentile from a histogram of rating buckets maintained by the ranking workers: "top 38%" is honest and cheap, and nobody below the top tier cares whether they are 31,440,118th or 31,440,190th.