Design an Online Game Leaderboard
Build a system for a game played N billion times per day that retrieves a user’s score, the K global scores surrounding it, and the K scores around the user within their friends list. The system must handle requests in near real-time.
Asked at:
Meta
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to view their current score and global rank in near real-time.
Users should be able to see the K scores immediately above and below them on the global leaderboard.
Users should be able to see the K scores around them among their friends only.
Users should be able to see top-N leaderboards (e.g., daily/seasonal top lists) that refresh near real-time.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Tips: Explain sharding and rank computation. A common approach is to shard a Redis ZSET (or similar) by score ranges or hash of userId and maintain per-shard sorted sets plus shard-level cardinalities. Compute exact rank by combining local rank (ZRANK/ZCOUNT within the shard) with prefix sums of counts from higher-score shards maintained in a small, frequently refreshed index. Discuss write coalescing (e.g., Kafka with compaction keyed by userId), monotonic scores, and update rate-limiting to avoid thrashing.
Tips: For global, use ZRANK + ZRANGE(ZREVRANGE) around the user's index. For friends, avoid materializing per-user friend ZSETs (too expensive). Instead, fetch the friend list (bounded, e.g., <= 5k), batch-get their scores from a low-latency KV/cache (MGET), sort in memory, and slice K-around; cache the result briefly (e.g., a few seconds). Outline fallbacks for very large friend graphs (cap friend count, sample, or precompute top-N friends sets) and discuss tail latency mitigation with hedged reads.
Tips: Discuss separating the global Top-M into its own small, highly replicated structure updated by a merger service that incrementally merges shard heads (like a k-way merge), reducing contention on the hot set. Use write debouncing per user (e.g., at most once per second), idempotent upserts, and request collapsing. Consider multi-leader or quorum writes for durability while keeping the hot path in memory, and explain backpressure during update storms.
Tips: State clear semantics: deterministic tie-breakers (score desc, then lastUpdate asc, then userId), time-windowed boards (daily/seasonal with TTL/epoch keys), and idempotent updates keyed by (userId, epoch). For recovery, rebuild Redis from the durable store via a Kafka replay or snapshot, warm top shards first, and allow eventual consistency for non-top ranks. Explain how you prevent duplicate increments and how you handle late or out-of-order events.
Relevant Patterns
Relevant patterns that you should know for this question
The product requires near real-time visibility of ranks and neighbor windows after each game. You need streaming ingestion, push/pull cache refresh, and mechanisms like debouncing and incremental merges to surface updates within seconds without overwhelming storage.
N billion daily games translates to massive write throughput. You must design append/compacted streams, idempotent upserts, per-user coalescing, and horizontally sharded in-memory indices to avoid global locks and full re-sorts on each write.
Leaderboards inherently create hotspots at the top ranks and around celebrities. Techniques like sharded ZSETs, top-K merger services, write throttling, and request collapsing are essential to prevent thundering herds and lock contention.
Relevant Technologies
Relevant technologies that could be used to solve this question
Similar Problems to Practice
Related problems to practice for this question
Both require maintaining and serving frequently changing top lists with low latency under heavy writes. Techniques like sharded heads, incremental merges, and approximate/interval recomputations carry over directly.
Real-time, high-fan-in updates with hotspots and the need to surface near real-time views to many users are shared challenges. Contention control, streaming ingestion, and cache-first read paths are similar.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Single monolithic sorted set or database table for the entire leaderboard
This creates a single hot shard and global lock contention, will not scale to N billion updates/day, and becomes a single point of failure. Interviewers expect horizontal sharding and cache-first designs.
Computing friend K-around by querying and sorting all friends synchronously from the primary store on every request
This yields high tail latency and excessive read amplification. You need a cache of per-user scores, batch gets (MGET), small in-memory sorts, and short-lived result caching to meet near real-time SLAs.
Requiring strong global consistency of rank after every update
Insisting on immediate, exact global rank recomputation across shards will blow latency budgets and throughput. Accept eventual consistency with periodic shard-prefix updates and exactness only where needed (e.g., top-K).
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late August, 2025
Meta
Senior Manager
Mid August, 2025
Meta
Staff
Mid August, 2025
Meta
Manager
Design a gaming leaderboard to show top 10 , user rank , +4 above and +4 below the user and top 10 users friends
Your account is free and you can post anonymously if you choose.