Designing Scalable Game Leaderboards with Redis: Core Requirements, Data Structures, and Architecture

Core Requirements

Game leaderboards for titles like Honor of Kings and Genshin Impact must satisfy real‑time updates within one second, support billions of users with daily tens of millions of updates, handle millions of QPS, provide precise ordering (including timestamp tie‑breakers), and be horizontally scalable.

Data Structures

Redis ordered sets (ZSET) combined with hash tables are used: the skip‑list of ZSET gives O(log N) sorting, while the hash table enables O(1) member queries.

Key API Performance

Typical operations include score updates, top‑N retrieval, rank lookup, and range counting.

Core Commands

# Update player score (increment)
ZADD leaderboard 1500 player_001
ZINCRBY leaderboard 200 player_001
# Get TOP10 (descending)
ZREVRANGE leaderboard 0 9 WITHSCORES
# Get player rank
ZREVRANK leaderboard player_001
# Count members in score range
ZCOUNT leaderboard 1000 2000

Billion‑Scale Architecture

Hot‑Key Sharding : Split keys like season_rank into shards season_rank_shard_0‑9 using CRC16 routing, then aggregate with ZUNIONSTORE .

import crc16
def get_shard_key(player_id, base_key="season_rank", shards=10):
    crc = crc16.crc16xmodem(player_id.encode())
    return f"{base_key}_shard_{crc % shards}"
shard_key = get_shard_key("player_12345")
redis_client.zadd(shard_key, 1500, "player_12345")

Dynamic Sharding : Apply a three‑level sharding strategy to overcome the ~20 k QPS write limit of a single ZSET.

Tiered Storage : Use hot ZSETs for ranking, while player attributes (avatar, VIP level) are stored in hashes to avoid frequent updates.

Read/Write Separation & Local Cache : Deploy master‑slave replication with Guava second‑level cache for read‑heavy workloads.

Pipeline Batch Retrieval : Fetch top‑N members with ZRANGE , then pipeline HGET calls to obtain detailed data, reducing latency from O(N) to O(1).

Persistence Strategy

# redis.conf
save 3600 1          # snapshot every hour
appendfsync everysec # AOF every second
aof-use-rdb-preamble yes # hybrid persistence

Disaster Recovery & Monitoring

Deploy active‑active clusters across Shanghai and Shenzhen, use Hystrix circuit breaking, and monitor key metrics such as hot‑key QPS (>100 k), P99 latency (<50 ms), and memory fragmentation (<1.5%).

By leveraging Redis ZSETs with careful sharding, tiered storage, and robust monitoring, game leaderboards can reliably serve billions of users with low latency and high availability.