How many users - 1M, 100M, 1B?

100M users. 100K score updates/sec at peak. 500K leaderboard reads/sec at peak. Top-100 query: 80% of read traffic. User-rank lookups: 15%. Range queries: 5%. Multiple leaderboards: ~100 active simultaneously.

Latency target for updates appearing in leaderboard - real-time (<1s), eventual (<1min)?

Score update p99 < 50ms. Top-100 read p99 < 10ms (cached). User-rank lookup p99 < 50ms. Deep range query (rank 50000+) p99 < 200ms. Leaderboard freshness: real-time tier sees updates within 1s; eventual tier within 60s.

Distributed Systems

Design a Leaderboard at Scale (Redis sorted sets, sharding)

Hard Premium

Redis sorted sets, sharding strategies, real-time vs eventual updates, top-K queries, hot keys, deep pagination - the deceptively-simple problem that breaks at 100M users.

The problem

Design a leaderboard for a game (or any ranking system) with 100M users. Users earn points; the leaderboard shows the top-100 globally and each user's own rank + neighbors. Updates must be near-real-time during peak events. The system must handle a release-day spike of 1M users hitting the leaderboard simultaneously without melting the cache.

This is the deceptively-simple problem. A naive Redis-sorted-set implementation works for 1M users. At 100M, it breaks: hot keys, slow ZRANGE queries on deep pages, sharding the sorted set across nodes, real-time global updates - each is a senior-level conversation.

Strong candidates start with ZADD/ZRANGE, then walk through sharding strategies, the hot-key problem, and the trade-off between real-time and eventual consistency. Excellent candidates discuss the "user X's rank" query (which is harder than top-K) and explain why deep pagination requires specialized data structures.

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→How many users - 1M, 100M, 1B?
→Update frequency - per game event (high), or aggregated daily?
→Read patterns - top-100 only, or any rank slice (rank 5000-5050)?
→Latency target for updates appearing in leaderboard - real-time (<1s), eventual (<1min)?
→Multiple leaderboards (global, regional, friends-only, daily/weekly/all-time), or just one global?
→Tie-breaking strategy - by timestamp, by user ID, undefined?
→Anti-cheat / score validation - server-authoritative or client-trusted?
→Persistence requirements - durable across Redis restarts, or transient?

Requirements

Functional requirements

·Submit score: increment a user's score atomically
·Top-K: return the top N users with their scores and ranks
·User rank: return any user's current rank and score
·Neighbors: return ranks K-N to K+N around a user (the 'me and people near me' view)
·Range query: return any rank slice (e.g., ranks 1000-1050)
·Score history: optional, for time-series leaderboards (daily, weekly resets)
·Multiple leaderboards: global, regional, friends, by category

Non-functional requirements

Scale: 100M users. 100K score updates/sec at peak. 500K leaderboard reads/sec at peak. Top-100 query: 80% of read traffic. User-rank lookups: 15%. Range queries: 5%. Multiple leaderboards: ~100 active simultaneously.
Latency: Score update p99 < 50ms. Top-100 read p99 < 10ms (cached). User-rank lookup p99 < 50ms. Deep range query (rank 50000+) p99 < 200ms. Leaderboard freshness: real-time tier sees updates within 1s; eventual tier within 60s.
Availability: 99.9%. A leaderboard outage during a game event is a P1, not a P0 - users can keep playing and submit scores; the leaderboard catches up after recovery.
Consistency: Eventual is acceptable for the public leaderboard (a 1-2s lag is invisible to users). Strong consistency required for the user's own score after submit (read-your-writes).

The full walkthrough covers

Architecture components

·Score ingest API
·Score event stream (Kafka)
·Real-time leaderboard updater
·Sharded sorted-set store (Redis Cluster)
·Top-K aggregator
·Edge cache (CDN / Varnish)
·Rank lookup service
·Persistent score store (DynamoDB / RDS)
·Periodic snapshotter
·Multiple leaderboard manager

Deep dives

Redis sorted sets: the primitive that makes this tractable
Sharding the sorted set: by user vs by score range
Hot keys: when one shard or one query path melts
Real-time vs eventual: the freshness vs cost trade-off
Deep pagination and the rank-slice problem
Multi-leaderboard, time-windowed, and the resets problem

What's in the full walkthrough

Capacity estimation · architecture with all 10 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions

This system design walkthrough is part of Premium

Unlock it with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

Every system design walkthrough - capacity estimates, deep dives and trade-offs
Full-length AI mock interviews - 3 to 10 questions with follow-ups, up to 3 a day

View Plans

7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). Cancel anytime.

Companies that test this topic

Practice in interview format

Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.

Start a system design mock interview →

Distributed Systems

Design a Leaderboard at Scale (Redis sorted sets, sharding)

Hard Premium

Redis sorted sets, sharding strategies, real-time vs eventual updates, top-K queries, hot keys, deep pagination - the deceptively-simple problem that breaks at 100M users.

The problem

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→How many users - 1M, 100M, 1B?
→Update frequency - per game event (high), or aggregated daily?
→Read patterns - top-100 only, or any rank slice (rank 5000-5050)?
→Latency target for updates appearing in leaderboard - real-time (<1s), eventual (<1min)?
→Multiple leaderboards (global, regional, friends-only, daily/weekly/all-time), or just one global?
→Tie-breaking strategy - by timestamp, by user ID, undefined?
→Anti-cheat / score validation - server-authoritative or client-trusted?
→Persistence requirements - durable across Redis restarts, or transient?

Requirements

Functional requirements

·Submit score: increment a user's score atomically
·Top-K: return the top N users with their scores and ranks
·User rank: return any user's current rank and score
·Neighbors: return ranks K-N to K+N around a user (the 'me and people near me' view)
·Range query: return any rank slice (e.g., ranks 1000-1050)
·Score history: optional, for time-series leaderboards (daily, weekly resets)
·Multiple leaderboards: global, regional, friends, by category

Non-functional requirements

Scale: 100M users. 100K score updates/sec at peak. 500K leaderboard reads/sec at peak. Top-100 query: 80% of read traffic. User-rank lookups: 15%. Range queries: 5%. Multiple leaderboards: ~100 active simultaneously.
Latency: Score update p99 < 50ms. Top-100 read p99 < 10ms (cached). User-rank lookup p99 < 50ms. Deep range query (rank 50000+) p99 < 200ms. Leaderboard freshness: real-time tier sees updates within 1s; eventual tier within 60s.
Availability: 99.9%. A leaderboard outage during a game event is a P1, not a P0 - users can keep playing and submit scores; the leaderboard catches up after recovery.
Consistency: Eventual is acceptable for the public leaderboard (a 1-2s lag is invisible to users). Strong consistency required for the user's own score after submit (read-your-writes).

The full walkthrough covers

Architecture components

·Score ingest API
·Score event stream (Kafka)
·Real-time leaderboard updater
·Sharded sorted-set store (Redis Cluster)
·Top-K aggregator
·Edge cache (CDN / Varnish)
·Rank lookup service
·Persistent score store (DynamoDB / RDS)
·Periodic snapshotter
·Multiple leaderboard manager

Deep dives

Redis sorted sets: the primitive that makes this tractable
Sharding the sorted set: by user vs by score range
Hot keys: when one shard or one query path melts
Real-time vs eventual: the freshness vs cost trade-off
Deep pagination and the rank-slice problem
Multi-leaderboard, time-windowed, and the resets problem

What's in the full walkthrough

Capacity estimation · architecture with all 10 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions

This system design walkthrough is part of Premium

Unlock it with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

Every system design walkthrough - capacity estimates, deep dives and trade-offs
Full-length AI mock interviews - 3 to 10 questions with follow-ups, up to 3 a day

View Plans

7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). Cancel anytime.

Companies that test this topic

Practice in interview format

Start a system design mock interview →

Design a Leaderboard at Scale (Redis sorted sets, sharding)

The problem

Clarifying questions

Requirements

Functional requirements

Non-functional requirements

The full walkthrough covers

Architecture components

Deep dives

What's in the full walkthrough

This system design walkthrough is part of Premium

Start Your 7-Day Trial

Related system design topics

Distributed Cache

Real-Time Collab

Companies that test this topic

Practice in interview format

Design a Leaderboard at Scale (Redis sorted sets, sharding)

The problem

Clarifying questions

Requirements

Functional requirements

Non-functional requirements

The full walkthrough covers

Architecture components

Deep dives

What's in the full walkthrough

This system design walkthrough is part of Premium

Start Your 7-Day Trial

Related system design topics

Distributed Cache

Real-Time Collab

Companies that test this topic

Practice in interview format