Design a Real-Time Gaming Leaderboard

50,000 updates per second spread across many consumer instances. Increments in the score store are commutative, and totals only grow, so ZADD GT makes out-of-order writes from two consumers harmless: an older, smaller total can never overwrite a newer one.

Only authoritative game servers can publish results; clients never submit their own scores, which removes the most common cheating vector. Recording processed match ids makes the consumer idempotent, so Kafka redelivery never double counts a match.

• Sorted set member: player id. Score: a composite value points * 2^22 + (seasonEnd - lastUpdateSeconds). A month is under 2^22 seconds, so more points always means a higher score, the earlier player wins a tie, and the value stays within the 53 bit precision of a Redis score.

A single Redis primary handles 50,000 ZADD calls per second and holds 25 million members in a few gigabytes. Read replicas absorb rank queries. If the game grows past one node, the set is partitioned by score range: each shard owns a band of scores, and a player's global rank is the count of players in higher bands (kept in a small summary) plus their rank within their own shard.

Sorted sets are chosen over a relational query such as SELECT COUNT(*) WHERE score > ?, which needs an index scan proportional to rank and becomes slow for players far down the list. Sharding by player id hash was rejected because computing a global rank would require querying every shard. For hundreds of millions of players where exact ranks deep in the list are not needed, an approximate rank from a score histogram is a cheaper alternative.

• season_scores(season_id, player_id, points, last_updated_at)
• processed_matches(match_id, processed_at) with a TTL of a few days.

Writes are single-key atomic increments that return the new total, which these stores spread evenly by player id.

Redis persistence alone is not trusted for player scores, because a failover can lose the last second of writes. Keeping a durable store means a lost Redis node can be rebuilt by streaming all season scores back into a fresh sorted set, which takes minutes for 25 million rows.

• GET /leaderboard/top?season=&limit=100 returns ranked players.
• GET /leaderboard/me?season= returns { rank, score, above, below }.
• GET /leaderboard/friends?season= returns the player's friends ranked.

The top 100 changes slowly relative to read volume, so it is cached for one second and served to every caller. Friend leaderboards fetch the friend list (typically under a few hundred ids) and look up their scores with one ZMSCORE call, then sort in memory.

Friend boards are computed on read rather than maintaining a sorted set per player, which would multiply every score update by the number of followers. With small friend lists, the read-time cost is negligible.

Using a new key per season instead of clearing the existing set makes the reset instantaneous and leaves the previous season available for export, at the cost of briefly holding two seasons in memory.