Loading system design…
Loading system design...
Design a real-time gaming leaderboard system that handles score submissions from millions of concurrent players, maintains ranked leaderboards (global top-K, player rank, surrounding players, friend leaderboards), supports time-based resets (daily/weekly/monthly), pushes live updates via WebSocket, and validates scores against cheating — all with sub-second update propagation and < 50ms query latency.
| Metric | Value |
|---|---|
| Concurrent players | 10 million |
| Score submissions per second | 100,000 |
| Total players per leaderboard | 50 million |
| Leaderboard types per game | 4 (daily, weekly, monthly, all-time) |
| Games supported | 1,000+ |
| Top-K queries per second | 500,000 |
| Rank queries per second | 200,000 |
| WebSocket connections (viewers) | 2 million |
| Redis sorted set size (entries) | 50 million per leaderboard |
| Leaderboard update latency | < 1 second |
| Rank query response time | < 50ms |
Score submission: players submit scores (player_id, score, game_id, metadata); scores recorded in real-time; support both 'highest score wins' and 'lowest score wins' (e.g., speedrun) leaderboards
Global top-K: retrieve the global top-K players (e.g., top 100) sorted by score in real-time; any score update is reflected in the leaderboard within 1 second
Player rank query: given a player_id, return their absolute rank on the leaderboard (e.g., 'You are ranked #4,523 out of 50 million players') in < 50ms
Surrounding players: given a player_id, return players ranked immediately above and below them (e.g., ranks #4,520 – #4,526) for a relative leaderboard view
Multiple leaderboard types: support daily, weekly, monthly, all-time, and per-tournament leaderboards; each with independent rankings; time-based leaderboards auto-reset at period boundaries
Leaderboard pagination: browse the full leaderboard in pages (e.g., page 5 of 100-per-page = ranks #401–#500); efficient cursor-based or offset-based pagination over millions of entries
Friend/group leaderboard: given a player's friend list, return a leaderboard restricted to only those friends; support clan/guild leaderboards with aggregate scores
Real-time push updates: players viewing the leaderboard receive live score changes via WebSocket/SSE; top-K updates pushed to all active viewers within 1 second of score change
Anti-cheat score validation: validate submitted scores against game replay data or server-side game state before accepting into leaderboard; reject anomalous/impossible scores
Historical snapshots: preserve leaderboard snapshots at the end of each period (daily, weekly, tournament); archived for historical review and prize distribution
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In