Leaderboard Design

A leaderboard is a deceptively boring requirement that breaks naive implementations the moment scale, ties, or time windows enter the picture. This article is for senior engineers who already know “use Redis sorted sets” and need to make the engineering decisions underneath: which ranking semantics, how to break ties without lexicographic surprises, how to shard when a single ZSET stops being enough, and where to drop exact ranks for percentile estimates.

Why a relational database is the wrong default

Computing a player’s rank in SQL means counting how many players score higher:

1SELECT COUNT(*) + 1 AS rank2FROM   players3WHERE  score > (SELECT score FROM players WHERE id = :player_id);

With a B-tree index on score, the planner can do an index-only scan and walk only the higher-scoring portion of the index. That makes the query proportional to the player’s rank, not the table size: cheap for the top of the board, expensive for someone in the middle of millions, and hopeless without an index.

The AWS Database Blog’s leaderboard reference design reports ~35 s for an indexed nested rank query against a 50 M-row MySQL table, vs. sub-millisecond ZREVRANK on the same data, which is the canonical citation for “don’t compute ranks in your OLTP database”:

The relational system is paying for two things on every read:

1. Re-deriving ordering. SQL ranking functions (RANK(), ROW_NUMBER(), DENSE_RANK()) recompute a window over the partition on each query.
2. Index maintenance and lock contention on writes. A viral game with millions of concurrent score updates exhausts row-level locks and B-tree rebalancing budget long before throughput would otherwise saturate.

Redis sorted sets (ZSETs) push the ordering into the data structure itself, so reads do not have to re-derive it.

Mental model: the ZSET dual structure

Redis stores each sorted set in two indexes that share the same elements (above the small-collection listpack threshold)²:

• A skip list keyed by (score, member), ordered ascending. Provides O(log N) insertion, deletion, and rank lookup.
• A hash table keyed by member, mapping to the score. Provides O(1) score lookup.

Each skip list node stores a span count along its forward pointers. Walking from the head to a member sums the spans of the pointers traversed; that sum is the rank. This is why ZRANK is O(log N) instead of O(N) — it is a search, not a scan³.

Core commands and their costs

All complexities are documented on the per-command pages of the Redis reference⁴⁵⁶.

M is the number of returned elements. Redis 6.2 unified ZRANGEBYSCORE, ZREVRANGEBYSCORE, and ZRANGEBYLEX into the ZRANGE command with BYSCORE / BYLEX / REV modifiers; the older variants still work but are deprecated.

1import redis23r = redis.Redis()45r.zadd("game:lb", {"player_1": 1500, "player_2": 1200, "player_3": 1500})6r.zincrby("game:lb", 100, "player_2")  # atomic delta, no read-modify-write78top_10 = r.zrevrange("game:lb", 0, 9, withscores=True)910rank = r.zrevrank("game:lb", "player_2")  # 0-indexed rank, descending11me = r.zrevrank("game:lb", "player_2") or 012window = r.zrevrange("game:lb", max(0, me - 5), me + 5, withscores=True)

Tie handling: lexicographic by default

Scores are IEEE 754 64-bit doubles, so distinct integer scores up to 2⁵³ are exact, and floats outside that band may be approximated. When two members have the same score, Redis falls back to a byte-by-byte memcmp of the member string⁷:

1> ZADD lb 100 alice 100 bob 100 charlie2> ZREVRANGE lb 0 -1 WITHSCORES31) "charlie"42) "100"53) "bob"64) "100"75) "alice"86) "100"

Reverse-iterating the same-score band orders them charlie > bob > alice because c > b > a. This is almost never the ordering a competitive product wants. Two players who both score 100 should be ranked by who got there first, not by username. Without an explicit tie-breaker the displayed order is also stable across restarts (it is purely a function of the score and member bytes, not insertion order), but it ignores intent. Always pick a tie-breaking strategy.

Ranking semantics: dense, sparse, unique

There are three industry-standard ways to translate “two players are tied” into rank numbers, and they map 1:1 onto SQL window functions⁸.

Redis ZSETs give you unique ranking by default because the (score, member) skip list is totally ordered by the lexicographic tie-break. ZREVRANK returns a 0-indexed unique position; subtract from ZCARD for the inverse direction.

Implementing dense and sparse rank

Dense rank requires counting distinct scores above the player’s score, not members. There is no native primitive — you have to compute it on read:

1import redis23r = redis.Redis()45DENSE_RANK_LUA = """6local scores = redis.call('ZREVRANGEBYSCORE', KEYS[1], '+inf', ARGV[1], 'WITHSCORES')7local seen, n = {}, 08for i = 2, #scores, 2 do9    local s = scores[i]10    if not seen[s] then seen[s] = true; n = n + 1 end11end12return n13"""1415def dense_rank(key: str, member: str) -> int | None:16    score = r.zscore(key, member)17    if score is None:18        return None19    distinct_above = r.eval(DENSE_RANK_LUA, 1, key, f"({score}")20    return int(distinct_above) + 12122def sparse_rank(key: str, member: str) -> int | None:23    score = r.zscore(key, member)24    if score is None:25        return None26    return r.zcount(key, f"({score}", "+inf") + 1

sparse_rank is O(log N) — ZCOUNT walks the skip list. dense_rank is bounded by the number of members with strictly higher scores; it is fine for the top of the board and a footgun in the long tail. Cache it.

Tie-breaking: pick one and live with the trade-off

Three patterns cover almost every real product. Pick by what your tie-break needs to express, then by whether you can afford precision loss.

Strategy 1 — composite score (encode the tie-breaker into the float)

Pack the primary score and the inverted tie-breaker into a single double or int64. Higher primary → larger top bits; earlier timestamp → larger reversed-ts bottom bits. Same ZADD, same complexity, no second round-trip.

1MAX_INT32 = 2**31 - 123def encode_score(score: int, ts_seconds: int) -> int:4    """Pack a non-negative 32-bit score and a reversed timestamp into int64.56    Constraints:7      - `score` must fit in 31 bits (~2.1B) to stay inside the IEEE 754 exact-integer band.8      - `ts_seconds` must be a Unix timestamp in seconds (fits int32 until 2038).9    """10    reversed_ts = MAX_INT32 - (ts_seconds & MAX_INT32)11    return (score << 32) | reversed_ts121314def decode_score(packed: int) -> tuple[int, int]:15    score = packed >> 3216    reversed_ts = packed & MAX_INT3217    return score, MAX_INT32 - reversed_ts

Trade-offs:

• Pros. Single atomic write. Native sort. No reads on the hot path.
• Cons. Primary score is capped (here ~2.1B). Doubles lose integer precision past 2⁵³; if you pack into a float instead of an int64 the precision budget is even tighter⁴.

This is the right default for almost every gaming or fitness leaderboard.

Strategy 2 — secondary hash (ZSET for primary, HASH for tie-breaker)

Keep the score in the ZSET; store the tie-breaker (timestamp, account age, region, whatever) in a separate Redis hash. Resolve ties on read.

1import time23def update_score(lb: str, player: str, score: int) -> None:4    pipe = r.pipeline(transaction=True)5    pipe.zadd(lb, {player: score})6    pipe.hset(f"{lb}:ts", player, time.time())7    pipe.execute()89def top_with_tiebreak(lb: str, n: int) -> list[tuple[str, float]]:10    rows = r.zrevrange(lb, 0, n * 2, withscores=True)11    members = [m for m, _ in rows]12    ts = r.hmget(f"{lb}:ts", members)13    enriched = [(m, s, float(t or 0)) for (m, s), t in zip(rows, ts)]14    enriched.sort(key=lambda x: (-x[1], x[2]))  # score desc, ts asc15    return [(m, s) for m, s, _ in enriched[:n]]

Trade-offs:

• Pros. Full precision. Tie-breaker can be richer than a number (region, account age).
• Cons. Two round-trips per write (use MULTI/EXEC or pipeline). Boundary correctness — you must over-fetch and re-sort, otherwise a tied player straddling the page boundary disappears.

Strategy 3 — encode the tie-breaker into the member string + ZRANGEBYLEX

When every member shares the same score (e.g., a “first to claim the daily quest” board), use ZRANGEBYLEX with a fixed score and put the tie-breaker into the member string itself.

1MAX_TS = 10**1323def make_member(player_id: str, ts_ms: int) -> str:4    reversed_ts = MAX_TS - ts_ms5    return f"{reversed_ts:013d}:{player_id}"67# All members get score 0; ZRANGEBYLEX walks them in tie-breaker order.

ZRANGEBYLEX’s contract requires all members to share the same score; with mixed scores the result is unspecified⁷. Note: ZRANGEBYLEX is deprecated since Redis 6.2 in favour of ZRANGE key min max BYLEX.

Decision matrix

Time-windowed leaderboards

Most products run several leaderboards in parallel: today’s, this week’s, this month’s, all-time. The mechanical pattern is one ZSET per window, named after the window so cleanup is trivial:

1from datetime import datetime, timezone23def time_window_keys(base: str, now: datetime | None = None) -> dict[str, str]:4    now = now or datetime.now(timezone.utc)5    iso_year, iso_week, _ = now.isocalendar()6    return {7        "daily":   f"{base}:daily:{now:%Y%m%d}",8        "weekly":  f"{base}:weekly:{iso_year}W{iso_week:02d}",9        "monthly": f"{base}:monthly:{now:%Y%m}",10        "alltime": f"{base}:alltime",11    }1213def update_all(base: str, player: str, delta: int) -> None:14    keys = time_window_keys(base)15    pipe = r.pipeline(transaction=True)16    for k in keys.values():17        pipe.zincrby(k, delta, player)18    # only set TTL on time-windowed boards, never on alltime19    pipe.expire(keys["daily"],   2 * 24 * 3600)20    pipe.expire(keys["weekly"],  14 * 24 * 3600)21    pipe.expire(keys["monthly"], 40 * 24 * 3600)22    pipe.execute()

Two things that look like they should be obvious and are not:

For historical archival, freeze the top of the board into a Redis Stream (XADD) or a relational warehouse on rollover. Do not try to keep the live ZSET around indefinitely “just in case” — every dead window costs memory.

Friend leaderboards: intersecting a global ZSET

A “ranked among your friends” view is the highest-volume non-global query on most consumer leaderboards. The naive approach — ZSCORE per friend, sort client-side — costs one round-trip per friend (or one pipelined batch of N round-trips). For a player with 200 friends and a 5 ms hop, that is at minimum 5 ms of pipelined work per request, plus the bandwidth of returning every friend’s score.

ZINTERSTORE does it in a single command. Store each player’s friends as a SET of member ids; intersect that with the global leaderboard ZSET, taking scores only from the global side via WEIGHTS 1 0:

1def friend_board(viewer: str, page: int = 0, page_size: int = 20):2    dest = f"lb:f:{viewer}"3    r.zinterstore(4        dest,5        {"lb:alltime": 1, f"user:{viewer}:friends": 0},  # weight 0 on friends -> score = lb:alltime score6        aggregate="SUM",7    )8    r.expire(dest, 60)  # keep around for follow-up paginated reads9    start, end = page * page_size, (page + 1) * page_size - 110    return r.zrevrange(dest, start, end, withscores=True)

Cost. ZINTERSTORE is documented at O(N*K) + O(M*log(M)) where N is the size of the smallest input, K is the number of inputs, and M is the result size⁹. For a friend list of 200 against a 100 M-member global ZSET, N = 200 (Redis iterates the smallest set and probes the others), so cost is dominated by friend-list size, not by global ZSET size. That is the same bound as the pipelined ZSCORE approach in compute, but it removes the network round-trips and the client-side sort.

Operational notes:

• Cache the materialised set. A short TTL (15 – 120 s) absorbs the repeat reads from infinite-scroll UIs without re-running the intersection. Invalidate on friend-graph mutations, not on every score change.
• In Redis Cluster, hash-tag. lb:{game1}:alltime and user:{game1}:42:friends keep the inputs and the destination on one slot; otherwise ZINTERSTORE hits CROSSSLOT.
• Friend graph belongs in a SET, not a hash or list. Sets give you the O(1) per-element membership checks ZINTERSTORE relies on; lists would force a scan.
• For very large friend lists (multi-thousand: streamers, “follow” graphs), prefer a precomputed per-viewer ZSET that you maintain incrementally on score changes — the intersection cost becomes painful at the tail of the distribution.

Scaling beyond a single Redis instance

A single ZSET is constrained by two limits.

• Memory. With the skiplist+hashtable encoding, community measurements and the redis-db mailing list thread put per-element overhead at roughly 100 – 170 B plus the member string. Using MEMORY USAGE on your own keys is the only way to know precisely. A 100 M-member ZSET with short opaque member IDs realistically lands in the 15 – 25 GB range; budgets that have circulated as “8 GB for 100 M” do not match the encoding overhead.
• Throughput. Redis executes commands single-threaded. On modern hardware, official benchmarks and the Arm Cobalt 100 benchmark show ~130 – 140k ops/s for individual ZADD operations on a single instance, climbing well past that with pipelining¹¹. The practical write ceiling for a single ZSET is in that 100k – 200k ops/s band, depending on payload size and latency target.

When either ceiling is in sight, partition.

Score-range partitioning

Bucket the keyspace by score, not by hash. The natural shape of a leaderboard — heavy-tailed, with most queries clustered around the top — falls out of this layout cleanly.

1SHARDS = [2    (0,        999,         "lb:s0"),3    (1_000,    9_999,       "lb:s1"),4    (10_000,   99_999,      "lb:s2"),5    (100_000,  float("inf"), "lb:s3"),6]78def shard_for(score: float) -> str:9    for lo, hi, key in SHARDS:10        if lo <= score <= hi:11            return key12    return SHARDS[-1][2]1314def update(player: str, old: float | None, new: float) -> None:15    new_key = shard_for(new)16    if old is not None and shard_for(old) != new_key:17        pipe = r.pipeline(transaction=True)18        pipe.zrem(shard_for(old), player)19        pipe.zadd(new_key, {player: new})20        pipe.execute()21        return22    r.zadd(new_key, {player: new})2324def global_rank(player: str, score: float) -> int:25    own = shard_for(score)26    higher = sum(r.zcard(key) for lo, _, key in SHARDS if lo > score)27    in_shard = r.zrevrank(own, player) or 028    return higher + in_shard + 1

Properties:

• Top-N. Read only the highest non-empty shard.
• Neighbour queries. Stay within one shard for any player not at a bracket boundary.
• Global rank. O(shards) round-trips. Cap shards at small constants and cache ZCARD per-shard with short TTLs (or maintain it via INCR/DECR on every move).
• Score crosses a boundary. Atomic ZREM + ZADD across two keys. In Redis Cluster, force shard keys onto the same slot with hash tags (e.g., lb:{game1}:s0, lb:{game1}:s1) or run cross-slot moves through application code.

Redis Cluster: the single-key constraint

A Redis Cluster shards by key hash, not by content. A single ZSET key is owned entirely by one node. No matter how big it gets, it cannot be split — if you outgrow the node, you must split the key. Hash tags like lb:{game1}:s0 constrain related keys to the same slot so multi-key commands keep working without CROSSSLOT errors¹², at the cost of correlated load on that slot.

Hash-sharded leaderboard with a periodic top-K aggregator

Score-range partitioning works when the score axis is a stable, bounded distribution. When it isn’t — viral games, billion-player platforms, or when one shard would blow past the per-instance ceiling no matter how you slice the score axis — fall back to hash sharding by player id, with a periodic aggregator that maintains an exact top-K.

The pattern shows up under different names — DynamoDB’s write-sharding pattern for leaderboards is the same shape with partition_id as the shard key and a Global Secondary Index for ordering; Apache Pinot/Flink “design YouTube top-K” pipelines do it for view counts; the canonical algorithm is k-way merge over a bounded heap of size K.

1import heapq23SHARDS = [f"lb:s{i}" for i in range(N)]4TOP_K = 1000  # global top to maintain56def write(player: str, delta: int) -> None:7    shard = SHARDS[hash(player) % N]8    r.zincrby(shard, delta, player)910def rebuild_global_top() -> None:11    pipe = r.pipeline()12    for shard in SHARDS:13        pipe.zrevrange(shard, 0, TOP_K - 1, withscores=True)14    per_shard = pipe.execute()15    merged = heapq.nlargest(16        TOP_K,17        ((m, s) for rows in per_shard for m, s in rows),18        key=lambda x: x[1],19    )20    pipe = r.pipeline(transaction=True)21    pipe.delete("lb:global-top")22    if merged:23        pipe.zadd("lb:global-top", {m: s for m, s in merged})24    pipe.execute()

Properties:

• Top-N reads are O(log K + N) against lb:global-top. Exact for any N ≤ K, between aggregator runs.
• Per-player rank is O(log N_shard) against the player’s own shard via ZREVRANK. The shard owns the full slice, so neighbour windows around the player work without cross-shard coordination.
• Aggregator cadence is the staleness budget. 1 – 10 s is usual for live leaderboards; tournament UIs that need true real-time at the top should keep the top tier on a single dedicated ZSET (the score-range top shard) and use hash sharding for the long tail underneath.
• Soundness of the merged top-K. Pulling top-K from each of N shards and merging gives the exact top-K of the union — every member of the global top-K is in at least one shard’s top-K, because if it weren’t, that shard would have K members above it, contradicting global-top-K membership.

Region or game partitioning

For multi-game platforms or multi-region deployments, the partition boundary tends to come from product anatomy, not from score:

1lb:fortnite:na-east2lb:fortnite:eu-west3lb:valorant:na-east

Each is an independent leaderboard with its own scaling story. Cross-region “global” boards are usually computed offline by a periodic rollup job, because synchronously merging multiple geographically distant ZSETs blows your latency budget.

Approximate ranking for the long tail

Below the top thousand or so, exact rank stops mattering to players. The product question becomes “am I better than 80 % of users?”, not “am I rank 4,217,338 or 4,217,339?”. The hybrid pattern below pays for exactness only where exactness matters.

1TOP_N = 100_00023def update_score(player: str, score: int) -> None:4    r.zincrby("lb:scores", score, player)5    threshold = r.zrevrange("lb:top", TOP_N - 1, TOP_N - 1, withscores=True)6    cutoff = threshold[0][1] if threshold else 07    if score >= cutoff:8        r.zadd("lb:top", {player: score})9        r.zremrangebyrank("lb:top", 0, -TOP_N - 1)1011def lookup(player: str) -> dict:12    rank = r.zrevrank("lb:top", player)13    if rank is not None:14        return {"rank": rank + 1}15    score = r.zscore("lb:scores", player)16    if score is None:17        return {}18    higher = r.zcount("lb:scores", f"({score}", "+inf")19    total = r.zcard("lb:scores")20    return {"percentile": round((1 - higher / total) * 100, 1)}

Sketch alternatives for true streaming top-K

When the goal is “trending top-K” rather than “leaderboard top-K” — billions of events with mostly long-tail entities, where you do not want to keep a full ZSET — the streaming literature has two standard structures¹⁴:

• Count-Min Sketch + min-heap of size K. The CMS holds a frequency estimate for every member with bounded over-count; a heap of size K tracks the top tier. Update path is O(d) hashes; lookup path is O(d) plus heap maintenance. Mergeable across shards. Redis Stack exposes this via the CMS.* and TOPK.* commands.
• Space-Saving (Metwally et al., 2005). Maintains exactly K monitored counters. Each event either increments a tracked counter or evicts the smallest tracked entry and replaces it. Stronger guarantees than CMS for top-K identification — exact under skewed (Zipfian) distributions, which describe most real leaderboards.

Use these when the membership cardinality breaks the ZSET budget (e.g., per-second viewer leaderboards), not for player leaderboards where the membership cardinality is just “your registered users”.

Write path: anti-cheat and validation

The leaderboard is the most attractive surface in any competitive product. The write path has to assume every payload is hostile and apply layered checks before it touches the ZSET.

Two concrete patterns:

1. Trusted writes path on the platform — Steam’s leaderboards expose a “Writes: Trusted” mode that disables client submission and forces score updates through ISteamUserStats::SetLeaderboardScore from a server identity¹⁰. If you run on Steam, set this and never look back.
2. Tentative-then-promote — for in-house systems that cannot run authoritative game logic for every match, accept the score into a lb:pending ZSET, surface it as “pending” in the UI, and let an async replay validator promote it to the canonical board only after re-running the recorded inputs server-side. This is the pattern recommended for non-server-authoritative leaderboards on the Game Development Stack Exchange.

Durable storage and historical archive

The Redis ZSETs are the index. The score history — every accepted submission, the inputs that produced it, the audit trail of moderator actions — belongs in a durable store. Two patterns are common:

• Cassandra / DynamoDB wide-row. Partition by (leaderboard_id, time_bucket) and cluster by (score DESC, player_id). The classical wide-row pattern keeps related rows co-located and uses TimeWindowCompactionStrategy for write-friendly time-series storage¹⁶. Cap partition size by choosing a bucket granularity that keeps each partition under ~100 MB; for hot leaderboards, add a bucket_id = hash(player_id) % B to the partition key to avoid hot partitions¹⁷.
• Append-only event log. Every accepted submission is an immutable event in Kafka / Kinesis / a Redis Stream; the leaderboard ZSET and the durable store both materialise from that log. This is the same shape as Netflix’s Distributed Counter Abstraction “Eventually Consistent Global” mode and gives you idempotency, replay, and bug-free rebuilds for free.

Either way: never let the live ZSET be the source of truth. A bad release that issues FLUSHALL should be a couple of hours of replay, not a permanent data loss.

Real-time updates

Push: WebSockets

Players watching a live board need rank deltas as they happen. The simplest pattern is to publish every score change on a per-player Pub/Sub channel:

1import asyncio2import json3import redis.asyncio as redis45r = redis.Redis()67async def subscribe(player: str, websocket) -> None:8    pubsub = r.pubsub()9    await pubsub.subscribe(f"lb:updates:{player}")10    async for message in pubsub.listen():11        if message["type"] == "message":12            await websocket.send(message["data"])1314async def notify(player: str, old: int, new: int) -> None:15    await r.publish(f"lb:updates:{player}", json.dumps({"old": old, "new": new}))

Pub/Sub is at-most-once: subscribers that miss a message do not get a replay. For boards where the player must see every change (e.g., money-on-the-line tournament UIs), publish to a Redis Stream instead and let the client consume by ID.

Batched writes

When score updates outpace the displayed refresh rate, batch them client-side and flush at the cadence of the UI:

1import asyncio2from collections import defaultdict34pending: dict[str, int] = defaultdict(int)5lock = asyncio.Lock()67async def queue(player: str, delta: int) -> None:8    async with lock:9        pending[player] += delta1011async def flush() -> None:12    async with lock:13        if not pending:14            return15        snapshot = pending.copy()16        pending.clear()17    pipe = r.pipeline()18    for player, delta in snapshot.items():19        pipe.zincrby("lb:alltime", delta, player)20    await pipe.execute()2122async def flusher() -> None:23    while True:24        await asyncio.sleep(0.1)25        await flush()

A 100 ms flush window is a 10× reduction in network round-trips for 10 ops/s/player workloads, in exchange for 100 ms of staleness — fine for almost every leaderboard, fatal for an order book.

Common pitfalls

1. Forgetting tie-breakers

Works in dev with three players. Fails in production the first time a Twitch streamer’s audience all hits the same achievement score. Players “swap” rank on reload because the lexicographic tie-break is based on the member byte string, not the order they reached the score.

Fix. Pick a tie-breaker before launch — composite score is the lowest-cost default.

2. ZREVRANGE 0 -1

Returns the whole leaderboard. With 1 M players that is a 50 MB+ payload over the wire and a long block on the Redis instance, because Redis is single-threaded and this command monopolises it.

Fix. Page everything. ZREVRANGE 0 99 for the first page, ZREVRANGE 100 199 for the next, and a “centred on me” window for the player’s own card.

3. Cross-shard global ranks on every request

The global_rank helper from the partitioning section issues ZCARD against every shard. With dozens of shards and a 1 ms hop per shard, that is tens of milliseconds of latency per request before you have served the rank — and it scales with shard count, not with player count.

Fix. Cache ZCARD per shard with a short TTL, maintain it in a single counter via INCR/DECR on every move, or read the merged lb:global-top for the top tier and only sum ZCARDs for ranks deep in the long tail. Recompute exact global rank only for the player’s own profile page, not for the leaderboard list view.

4. No TTL on time-windowed boards

After a year the Redis instance is sitting on 365 daily ZSETs and 52 weekly ZSETs you stopped reading nine months ago. Memory creeps until OOM.

Fix. Set TTL at write time. Use ZADD followed by EXPIRE inside a MULTI/EXEC so the TTL survives the first write into a new window key.

5. Non-atomic multi-board writes

Updating daily / weekly / all-time with three separate commands is fast and wrong. A timeout between commands leaves the player ahead in alltime but missing from weekly.

Fix. Wrap in MULTI/EXEC or a Lua script. In Redis Cluster, force the keys onto one slot with a hash tag.

Real-world examples

PlayFab (Microsoft)

PlayFab statistics implement leaderboards as versioned counters. Configurable VersionChangeInterval resets — Hour, Day, Week, Month, or Manual — bump the active version at the boundary; the previous version is preserved as a queryable archive¹⁸. Resets fire at midnight UTC, with Week cutting between Sunday and Monday.

Google Play Games Services

Every leaderboard automatically exposes daily, weekly, and all-time variants. Daily resets at midnight Pacific Time; weekly resets between Saturday and Sunday at midnight Pacific Time¹⁹. Game developers do not configure or manage rollover — the variants are always present in the SDK.

Steam (Valve)

Steam exposes leaderboards as a hosted service via ISteamUserStats. Each leaderboard is identified by a string name; an entry is a 32-bit integer score plus an optional array of up to 64 int32 “details” for session-specific metadata; a single title can host up to 10,000 leaderboards. Reads come in three modes — global, around-user, and friends — and the friends mode is the canonical hosted equivalent of the ZINTERSTORE pattern above. For competitive titles, Valve recommends setting “Writes” to Trusted in the Steamworks admin so client builds cannot submit scores at all; updates must come from a server identity through the Steam Web API¹⁰.

Blizzard — World of Warcraft Mythic+ leaderboards

WoW’s Mythic+ system exposes a per-realm-and-dungeon leaderboard via the official Blizzard API. The API is capped at the top 500 runs per realm/dungeon combination²⁰; as new high-keystone runs land, lower-ranked runs fall off, raising the de facto cutoff over time. The cap is the analogue of the “top-N ZSET + percentile for the rest” hybrid pattern: the platform decides exact ranks are only meaningful inside the top tier and refuses to serve more.

Netflix Counter Abstraction

Not a leaderboard, but the closest large-scale public reference for the “different parts of the surface need different consistency” lesson. Netflix’s Distributed Counter Abstraction exposes three modes against the same API:

• Best-Effort Regional — EVCache only, sub-millisecond, no cross-region replication, no idempotency. Good enough for A/B test counters.
• Eventually Consistent Global — every increment is an immutable event in their TimeSeries Abstraction (Cassandra-backed); a rollup pipeline aggregates. Single-digit millisecond reads, durable, idempotent via tokens.
• Accurate Global (experimental) — pre-aggregated rollup plus a live delta over unprocessed events. Higher read complexity, near-real-time accuracy.

The architectural lesson for leaderboards is the same: a competitive top-100 board and a “how do I rank in fitness this month” feed have very different consistency budgets, and bolting one design onto both is a recipe for over-engineering one and under-engineering the other.

Practical takeaways

• Default to a single ZSET with composite scores. Higher 32 bits = primary score, lower 32 bits = MAX_INT32 - timestamp. This handles ties for the lifetime of most products without a second round-trip.
• One ZSET per time window, with TTL. All writes must be atomic across the windows. Hash-tag the keys when running on Redis Cluster.
• Friend boards are a ZINTERSTORE away. Keep the friend graph in a SET, intersect with the global ZSET, take score from the global side, cache the materialised result on a short TTL.
• Partition by score for natural locality; switch to hash + aggregator when the top tier itself is too hot. Score-range keeps top-N and neighbour queries local; hash-shard with a periodic top-K aggregator when shard count must grow with player count, not score range.
• Treat the write path as hostile. Synchronous fast checks (rate limit, sanity, HMAC, anomaly z-score) on every write; tentative-then-promote with async replay validation for top-tier writes; trusted-server-only writes whenever the platform supports it.
• Go hybrid for the long tail. Maintain a “top N” ZSET for exact ranks; serve everyone else a percentile from the full ZSET (or a t-digest if ZCOUNT becomes the bottleneck). Use Count-Min Sketch / Space-Saving for true streaming top-K when you cannot afford a full ZSET.
• The ZSET is an index, not the source of truth. Keep the audit trail in an append-only log and a wide-row store (Cassandra / DynamoDB) so a bad release becomes a replay, not a data-loss incident.
• Audit the data model the first time a number looks suspicious. MEMORY USAGE and redis-benchmark against your actual member sizes will tell you within an order of magnitude what your real budget is — do not extrapolate from blog-post numbers.

Appendix

Prerequisites

• Working knowledge of Redis data types (strings, hashes, sorted sets) and the MULTI/EXEC model.
• Familiarity with O(log N) ordered structures (skip lists or balanced trees).
• A mental model of partitioning, replication, and the CAP-flavoured trade-offs between consistency and latency.

Terminology

• ZSET / sorted set — Redis data type storing unique members with associated double-precision scores, ordered by score and then by member byte order.
• Skip list — probabilistic ordered data structure with expected O(log N) search, insert, and delete; what Redis uses to back the ordered side of a ZSET.
• Listpack — compact contiguous encoding Redis uses for small ZSETs (default thresholds: ≤ 128 members, members ≤ 64 bytes); above the thresholds the ZSET is upgraded to skiplist + hashtable.
• Dense / sparse / unique rank — three ways of mapping ties to rank numbers, equivalent to SQL DENSE_RANK() / RANK() / ROW_NUMBER().
• Composite score — single numeric value packing primary score + tie-breaker; lets one ZADD capture multi-criteria ordering.
• Score-range partitioning — sharding strategy that buckets members by score range; preserves locality for top-N and neighbour reads.
• t-digest — mergeable, centroid-based probabilistic data structure for streaming quantile estimation; available in Redis Stack.
• HyperLogLog — probabilistic structure for cardinality (count-distinct), not for percentiles; Redis’s implementation has 0.81 % standard error in 12 KB.

Summary

• Redis ZSETs serve sub-millisecond rank operations because they keep the order in the data structure (skip list ordered by (score, member), hash table for O(1) score lookup).
• Without an explicit tie-breaker, ties resolve by member byte order — almost never what a competitive product wants. Composite-score encoding is the lowest-cost default tie-break.
• The three industry-standard ranking semantics (ROW_NUMBER, RANK, DENSE_RANK) translate directly to leaderboard requirements; only “unique” is free in Redis, the others cost extra reads.
• Time windows live in their own keys with TTL; multi-window updates must be atomic. Friend boards are ZINTERSTORE of the global ZSET with the friend SET.
• Past a single-instance ceiling, score-range partitioning preserves locality; hash-sharding with a periodic top-K aggregator scales further when score range is no longer a useful axis. The Redis Cluster CROSSSLOT constraint is unavoidable, so design for it.
• For hyperscale, mix exact ranks at the top with percentile estimates (or t-digest) in the long tail; Count-Min Sketch / Space-Saving cover true streaming top-K when a full ZSET is unaffordable.
• The write path is the cheating surface. Layered synchronous checks plus tentative-then-promote with async replay validation are the floor; durable storage (Cassandra wide-row, append-only log) makes the ZSET disposable.