Question 1

What data structure should you use for a real-time leaderboard?

Accepted Answer

Redis sorted set (ZSET). It maintains elements sorted by a floating-point score with O(log N) insertion, deletion, and rank queries. Key operations: ZADD leaderboard score player_id (insert or update), ZREVRANK leaderboard player_id (0-indexed rank from highest), ZREVRANGE leaderboard 0 99 (top 100), ZSCORE leaderboard player_id (get current score). A sorted set with 100M members uses ~10GB RAM — manageable on a high-memory instance or Redis Cluster. Never use a SQL table with ORDER BY for a real-time leaderboard at this scale — full table scans or index traversal can't match Redis's O(log N) for both writes and rank queries.

Question 2

How do you implement time-windowed leaderboards (daily, weekly)?

Accepted Answer

Maintain separate sorted sets per time window: ZADD leaderboard:{game}:daily:{YYYYMMDD} score player_id. On each score update, write to both the all-time sorted set and the current daily/weekly sorted set. Set EXPIREAT on time-windowed keys to auto-delete after the display window closes (e.g., daily key expires after 8 days so last week is still queryable). To query yesterday's top 100: ZREVRANGE leaderboard:{game}:daily:{yesterday} 0 99. Weekly: same pattern with a weekly key. For season-based leaderboards, create a new key per season and keep historical season keys indefinitely (or archive to cold storage).

Question 3

How do you prevent score regression from out-of-order updates?

Accepted Answer

Two mechanisms: (1) In the database: INSERT INTO scores (player_id, game_id, score) VALUES (%s, %s, %s) ON CONFLICT (player_id, game_id) DO UPDATE SET score = GREATEST(scores.score, excluded.score). GREATEST ensures the DB score only increases. (2) In Redis: before ZADD, check current score with ZSCORE. Only update if new_score > current. Or use Lua script for atomic check-and-update: if new score > current, call ZADD. However, brief inconsistency between DB and Redis is acceptable — the authoritative score is in the DB; Redis is the display cache. On server restart, rebuild the Redis sorted set from DB.

Question 4

How do you show a player their rank among friends?

Accepted Answer

For small friend lists (under 5000): use ZMSCORE leaderboard:{game} friend_id_1 friend_id_2 ... to fetch all friend scores in one Redis call. Sort the result in application code and find the player's position. For large friend lists: maintain a separate sorted set per user key=friend_board:{user_id}, updated when a friend's score changes. Fan-out on friend score change: for each player P, for each of P's friends F, update friend_board:{F}. Expensive if users have many friends. Compromise: precompute friend leaderboards hourly in a batch job instead of real-time, acceptable for casual games.

Question 5

How do you handle a leaderboard for 100 million players in one Redis instance?

Accepted Answer

A Redis sorted set with 100M members uses approximately 10GB RAM (each member: ~50 bytes score + ~50 bytes member string). This fits in a single high-memory instance (r6g.2xlarge has 64GB). For higher throughput: use Redis Cluster with multiple shards, each handling a partition of players. But cluster ZREVRANK across shards requires cross-shard coordination. Alternative: hash players into N sub-leaderboards (player_id mod N), accept approximate global ranks (rank in sub-leaderboard * N + offset). For true global ranking across shards: maintain a summary sorted set with shard-level scores, two-level lookup.

Game Leaderboard System Low-Level Design

Requirements

Core Data Structure: Redis Sorted Set

Data Model

Score Update Flow

Time-Windowed Leaderboards

Displaying the Leaderboard

Friend Leaderboard

Key Design Decisions