PHASE 12Advanced ~7 min· topic 36 of 39Level 6

System 12.36 — Real-Time Leaderboard

In one line

Rank millions of players by score in real time and show anyone's rank and neighbours instantly. Redis sorted sets do the heavy lifting; the design questions are durability, sharding very large boards, and time-windowed boards.

0/39 · 0%

Think of it like this

The live scoreboard at a marathon. Every runner's position updates as they cross checkpoints, and anyone can look up 'where am I, and who's just ahead and behind me?'.

Key ideas

01
Requirements: 25 M daily players, score updates on every match (~thousands/s), top 10 view, 'my rank' and players around me, daily/weekly/all-time boards, tie-breaking by earliest achiever.
02
Core: a Redis SORTED SET per board: ZINCRBY board:2026-09 50 player:42 updates a score in O(log N); ZREVRANGE board 0 9 WITHSCORES gives the top 10; ZREVRANK gives a player's rank; ranges around the rank give neighbours (Stateful course, Redis). A 25 M member sorted set uses a few GB of memory.
03
Durability & truth: the game service records every score change in a database (or an event log) first; Redis is a derived, rebuildable view. Ties: encode score * 10^10 + (MAX_TS - timestamp) so earlier achievers rank higher.
04
Scale beyond one node: shard by score range (fixed brackets, with per-shard counts to compute global ranks) or by player with a scatter-gather for the top K (merge each shard's top K). Time windows: one sorted set per period with expiry; seasonal archives go to the database.

Code & diagrams

sorted-set operationsbash

ZINCRBY lb:weekly:2026-39 120 player:42          # score update, O(log N)
ZREVRANGE lb:weekly:2026-39 0 9 WITHSCORES        # top 10
ZREVRANK lb:weekly:2026-39 player:42              # my rank (0-based)
ZREVRANGE lb:weekly:2026-39 1180 1200 WITHSCORES  # players around rank 1190
EXPIRE lb:weekly:2026-39 1209600                  # keep two weeks

Explain without notes

Why isn't a relational ORDER BY score LIMIT 10 enough at this scale?

Practice

Redis restarts and loses the weekly board. How do you recover?

Trade-offs

↔
In-memory sorted sets are fast and simple but bounded by memory and need a durable source; sharded boards scale but make global rank approximate or expensive.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Stateful · Redis & caching patterns

Cache-aside with a stampede lock, TTLs, rate limiting, and sessions in Redis.

Stateful · Redis Sentinel, Cluster & locks

Hash slots, failover, and why distributed locks need fencing.

Completion checklist

I can build a leaderboard on sorted sets with ties, windows, and recovery

Back to phase

Command Palette