Design a Real-Time Leaderboard Analytics

Problem statement

Design a real-time leaderboard analytics platform that maintains live rankings for millions of players across multiple game modes and seasons. The system ingests score events from match results, recomputes ranks without rescanning the population, answers top N and rank of user U queries in milliseconds, supports regional and global views, and survives partial outages without showing impossible ranks.

The naive design — a table of (user, score) sorted on read — collapses immediately. With 25M daily active players each producing several score events per session, and 80K+ score events per second at peak, a full resort is O(N log N) per update and a rank query is O(N). At 25M rows, that is seconds per query and impossible write amplification. The core engineering insight is that a leaderboard is a maintained aggregation structure: a histogram, balanced tree, or sharded sorted set that turns a score into a rank in logarithmic time and answers top-K by walking the structure.

The three distinct problems

1. Score ingestion. High-rate, at-least-once event delivery from match servers. Events arrive out of order, duplicated, and late. The ingestion plane must deduplicate by match event ID and decide last-write-wins vs best-score-wins semantics.
2. Rank maintenance. Every accepted score update mutates the rank index. The index must support point update and rank lookup in O(log N) without global locking. This is where most candidates stop at "Redis ZADD" and miss the sharding, hot-key, and rank-query-across-shards problems.
3. Rank serving. Reads vastly outnumber writes in a game: players check their rank constantly. Top-N pages, rank-around-me pages, and friend-rank views are different read shapes with different consistency tolerances.

Public operating baseline

Published industry signals establish scale context. Riot Games reported League of Legends peak concurrency above 8M simultaneous players during the 2019 Worlds period; ranked ladder systems with tier divisions and seasonal resets are the standard pattern in competitive titles (StarCraft II's ladder system is the canonical public reference design). Strava publicly operates segment leaderboards over a reported 100M+ athlete base where every new activity upload can change thousands of segment rankings. Duolingo publicly runs weekly league leaderboards for tens of millions of learners. These are cited public figures, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature platform: 100M registered players, 25M DAU, 3M concurrent at peak, 1.2B score events per day, 14K events/sec average, 80K events/sec at a 5-6x event peak (season finale, e-sports finals). Unless tied to a citation, every number is a stated design assumption.

The four architectural planes

1. Ingestion plane: match servers to gateway to dedup to stream. At-least-once delivery, idempotent apply.
2. Rank-index plane: the data structure that maps score to rank. Sharded, versioned, with a dual exact/approximate path.
3. Serving plane: rank query API, top-N cache, WebSocket fan-out for live rank movement.
4. Lifecycle plane: seasons, decay, resets, anti-cheat score reversal, historical snapshots.

A strong answer keeps the planes separate: an ingestion backlog must not corrupt the rank index, a serving cache miss must not stall ingestion, and a season reset must be a bounded, testable operation — not an untested migration.