Real-Time Leaderboards with Sorted Sets

Performance
34 / 47

A leaderboard needs 'top N' and 'what is my rank' to be fast while scores change constantly. A sorted set keeps members ordered by score so both are O(log n) instead of a full re-sort.

The Analogy (Read This First)

A scoreboard where each name slides up or down the board the moment its score changes, so you never re-sort the whole list.

Deep Dive Analysis

Why SQL struggles. SELECT ... ORDER BY score DESC LIMIT 10 is fine for the top, but 'what is my rank?' means counting every row with a higher score. With 50 million players and updates every second, that count is far too slow to run per request.

Sorted set. Redis keeps members in a skip list ordered by score. ZADD board 1520 player42 inserts or updates in O(log n). ZREVRANGE board 0 9 WITHSCORES returns the top 10. ZREVRANK board player42 returns a player's rank in O(log n). Those three operations are the whole leaderboard.

Neighbours around me. Fetch the player's rank r, then ZREVRANGE board r-5 r+5 to show the people just above and below. That 'around you' view motivates players more than the global top 10.

Ties. Scores of 900 and 900 need a rule. A common trick packs the tiebreaker into the score: score * 1e6 + (1e6 - timestamp_offset) so the earlier player wins. Decide the rule before you build the board.

Several boards. Daily, weekly and all-time boards are separate keys (board:2026-10-09, board:2026-W41). Expire the short ones with a TTL. ZUNIONSTORE can combine them for a custom window.

Scaling past one node. One sorted set holds millions of members comfortably. For hundreds of millions, shard by score range or by player id hash. Sharding by id spreads writes but makes 'global top 10' a merge of every shard's top 10, which is cheap: the global top 10 can only come from the shards' top 10s.

Durability. Redis is a fast view, not the source of truth. Write each score change to a durable store or log first (or alongside), so the board can be rebuilt after a crash or a bug.

Approximate ranks at huge scale. Showing 'top 1%' needs a bucketed histogram of scores, not the exact rank of every player. Exact ranks only need to be precise near the top.

Key Bullets
  • ZADD to update, ZREVRANGE for the top N, ZREVRANK for my rank - all O(log n).
  • Show the neighbours around a player, not just the global top.
  • Define the tie-break rule up front and encode it in the score.
  • Per-period boards are separate keys with TTLs.
  • Keep a durable source of truth; the sorted set is a rebuildable view.
Trade-offs
Redis sorted set: very fast rank and range | Memory-bound, needs a durable backupSQL ORDER BY: simple and durable | Rank queries are slow at scaleSharded boards: scale writes | Global views need a merge step
Real-World Examples
A game's global and friends-only leaderboardsA weekly sales contestA coding-contest scoreboard

Curated Curation & Deep Insights

ScaleDojo Certified
Video Tutorial Pending

Our system architects are vetting high-quality, authorized video guides for Real-Time Leaderboards with Sorted Sets with zero third-party platform links.

Verification in Progress
Reading Material Pending

We are preparing premium, zero-competitor deep-dives for Real-Time Leaderboards with Sorted Sets. Authorized reading references will appear automatically.

Verification in Progress