Design a real-time leaderboard for millions of players

Question

IT Interview Practice · Accepted Answer

**Use a Redis sorted set (ZSET) keyed by score: rank and top-N become O(log N) built-in operations, so you never sort millions of rows per request.** A ZSET keeps members ordered by score automatically; that is exactly what a leaderboard is.

## Architecture

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## How it works

- **ZADD** upserts a player's score in O(log N). Redis maintains order via a **skip list**, so no re-sort is needed.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` returns the top 100 in O(log N + 100).
- **Your rank**: `ZREVRANK board user` gives the 0-based position; **around-me** is `ZREVRANGE rank-5 rank+5` — the slice of players near you.
- **Durability**: Redis is in-memory. Enable **AOF** (append-only file) for replay, and asynchronously mirror scores to **Postgres** as the true system of record, so a Redis loss is recoverable.

## Sharding for millions of users

One ZSET holds tens of millions of members fine (memory-bound, ~100MB for 1M entries). Beyond that, or for global scale, **shard by score range** (0–1k, 1k–10k…) so each shard is a contiguous band — a global top-N reads only the top shard. Avoid sharding by user hash: recombining ranks across random shards is expensive.

## Interview perspective

The interviewer wants to see you **reach for the right data structure** rather than `ORDER BY score LIMIT 100` on SQL (which re-sorts on every hit and dies under write load). Good answers name ZSET; great answers cover **around-me queries, ties, persistence, and shard strategy**. A classic trap: forgetting Redis is volatile and treating it as the source of truth — a restart wipes the board unless AOF/RDB or a DB mirror exists.

## Trade-offs & failure modes

- **Ties.** Equal scores order by member lexicographically, which looks random. Encode a tiebreaker into the score (e.g. `score * 1e13 - timestamp`) so earlier achievers rank higher.
- **Hot key.** A single global ZSET is one key on one shard — a write hotspot. Buffer/batch `ZADD`s, or use time-bucketed boards (daily/weekly) to spread load.
- **Consistency.** Reads may lag the async DB mirror by seconds — fine for leaderboards, not for payouts; reconcile from Postgres before awarding prizes.
- **Memory cost.** Millions of members cost real RAM; expire seasonal boards with TTLs.
- **When not to:** a leaderboard of a few thousand refreshed every minute is fine as a cached SQL query — Redis ZSET shines when writes are constant and rank must be instant.

Architecture

How it works

Sharding for millions of users

Interview perspective

Trade-offs & failure modes

Related questions