Design a Game Leaderboard: Real-Time Ranks for 100M Players

The system records a score after each completed match, and on the global board only a player's personal best counts, so a bad game never pulls someone down. Anyone can view the global top 100. Each player can also see their exact position, not just a vague bucket, along with a handful of players directly above and below, which gives a sense of who to chase next.

Two extra views make the board social and keep it fresh. A friends leaderboard ranks a player only against people they know, which is often more motivating than a global list of strangers. Daily and weekly boards reset on a schedule, giving newer or casual players a realistic chance of reaching the top for a while.

Rank changes should be visible within about a second of a match ending, otherwise the board feels disconnected from play. Reads for the top 100 and a player's own rank should complete in under 50 milliseconds, since players open the screen often and expect it to snap into view.

Trust is a requirement in its own right. If the mobile client could submit scores, someone would quickly post an impossible number and hold first place forever, so only authoritative game servers may report results. Durability completes the list. The ranking structure lives in memory for speed, but every score is also persisted, so if the in-memory layer fails we can reconstruct every board without losing anyone's progress.

Assume 100 million players on the global board, with around 20 million playing on a given day and finishing about ten matches each. That yields roughly 200 million score updates per day, near 2.3K per second on average and about 10K at peak. Leaderboard views are lower: assume about 50 million a day, close to 580 per second with peaks around 3K.

Memory is the interesting figure. An entry in an in-memory sorted structure costs roughly 100 bytes including overhead, so 100 million players need about 10 GB. That fits on one server today, which is encouraging, but a breakout game could grow tenfold, and a single node is also a single point of failure. The design should work on one node yet leave a clear path to sharding and replication.

Three entities are enough: Player, Score (one per match) and Leaderboard. A leaderboard ID identifies which ranking is being asked about, such as the global board, the current week or a player's friends, so the same endpoints serve every variant.

POST /scores is internal and callable only by game servers; it carries the player ID, the match ID and the score, and returns 202 because the update is processed asynchronously. Including the match ID lets the updater ignore duplicates if a server retries. GET /leaderboards/{id}/top?n=100 returns ranked entries with player, score and position. GET /leaderboards/{id}/me returns the caller's rank, score and an around_me list of nearby players.

Matches run on game servers, and when one finishes the server, not the phone, publishes the result to a Kafka topic. A score updater consumes the topic at its own pace, so a sudden burst of match completions queues up harmlessly instead of overwhelming storage.

For each event, the updater first writes the score to the score database, which is the durable source of truth, and then applies it to Redis sorted sets that hold the live rankings. On the read side, the client goes through the API gateway to the leaderboard API, which answers top-N and rank queries directly from Redis. When a friends board is requested, the leaderboard API asks the friends service for the player's friend list and then looks up those players' scores. Redis provides speed; the database guarantees nothing is lost.

A Redis sorted set stores members ordered by a numeric score and supports exactly the operations a leaderboard needs. Recording a result uses ZADD with the GT flag, which only overwrites the stored value when the new score is higher, so best-score semantics come for free. ZREVRANGE board 0 99 WITHSCORES returns the top 100 from highest down.

A single player's position comes from ZREVRANK, which is exact even across 100 million members. To show the neighbourhood, take that rank and read a short range around it, five positions either side. Ties need a rule, typically that whoever reached the score first ranks higher. Encoding the points in the high part of a number and an inverted timestamp in the low part produces one composite value that sorts correctly.

All of this is fast because a sorted set combines a skip list, which keeps members in order, with a hash map for direct member lookup. Inserts, rank lookups and range reads are therefore O(log N), which stays in the microsecond range even for very large boards.

Keeping one huge sorted set gives exact answers with no extra logic, but it is capped by one machine's memory and CPU and concentrates every request on a single hot node. Sharding by score range makes rank easy to compute, yet the shard holding the top scores receives most of the traffic, and players constantly migrate between shards as their scores rise.

Sharding by a hash of the player ID spreads both memory and load evenly, so it is the chosen option. The top 100 is assembled by asking every shard for its local top 100 and merging the results; because almost everyone requests this list, the merged answer is cached for one second. An exact rank is the sum, across shards, of how many players have a higher score, found with ZCOUNT. With 16 shards queried in parallel this still completes in a few milliseconds.

Precise ranks matter much less deep in the list. A player at position 50 million gains little from the exact number, so the system can show a percentile such as "top 12%" computed from a score histogram, which avoids querying every shard.

Time-bounded boards are just additional sorted sets whose keys include the period, such as a daily key with the date and a weekly key with the ISO week number. The updater writes each score to the global, daily and weekly sets together. Each period key gets a TTL, and before it expires a job copies the final standings and winners to the database for rewards and history.

Friends boards are computed at read time rather than stored. A typical player has around 200 friends, so the API fetches their IDs, retrieves all their scores in one ZMSCORE call and sorts that small list in memory. Since players reopen this view frequently, each result is cached for a few seconds. If Redis is ever lost, every board can be rebuilt from the score database or by replaying the Kafka topic.

Keeping rankings in Redis makes them instant but costs more per gigabyte than disk, so the database remains authoritative. Exact ranks require consulting every shard, while percentiles are cheaper and good enough for players far from the top. Computing friends boards on demand keeps them simple and always current, at the cost of slightly more work per request.

Routing updates through Kafka smooths bursts, but a rank may trail the latest match by a fraction of a second. Put together: use sorted sets for speed, add shards as the player base grows, and rely on durable storage as the record of truth.