What is a leaderboard service in system design?

A leaderboard service is a backend system that tracks, ranks, and displays user scores or metrics in real time or near-real time. It typically involves a sorted data structure (such as a Redis sorted set) to efficiently retrieve top-N rankings and a user's relative position among millions of entries.

How do you handle real-time updates in a leaderboard system?

Real-time leaderboard updates are commonly handled using Redis ZADD and ZRANK commands on a sorted set, which provide O(log N) write and read complexity. Score changes are streamed via message queues (e.g., Kafka), and the leaderboard service consumes these events to update rankings without blocking the user-facing write path.

How do you scale a leaderboard service to support millions of users?

Scaling a leaderboard service involves sharding the sorted set by score range or user segment, caching the top-K results with a short TTL, and using read replicas for serving rank queries. For global leaderboards, a two-tier approach combines an in-memory store (Redis) for hot data with a persistent database (Cassandra or PostgreSQL) for historical snapshots.

What are common interview questions about leaderboard service design?

Common interview questions include: How would you design a leaderboard that supports 10 million concurrent users? How do you handle tie-breaking in rankings? How do you compute a user's percentile rank efficiently? How do you support both global and friend-scoped leaderboards? These are frequently asked at companies like Google, Amazon, and Snap.

Low Level Design: Leaderboard Service

⏱ 4 min read

What Is a Leaderboard Service?

A leaderboard service ranks users or entities by a numeric score and exposes that ranking to clients in real time or near-real time. Common in gaming, e-commerce, finance, and social platforms, it must handle high write throughput (score updates), low-latency reads (rank queries), and correct ordering under concurrent updates.

Data Model

The core data structure is a Redis Sorted Set, which stores member-score pairs and maintains ordering automatically.

ZADD leaderboard:global 4200 user:9871
ZADD leaderboard:global 3750 user:4412
ZINCRBY leaderboard:global 50 user:9871   -- atomic increment
ZREVRANK leaderboard:global user:9871      -- 0-indexed rank from top
ZREVRANGE leaderboard:global 0 99 WITHSCORES  -- top 100

A relational backing store persists canonical scores for durability and historical queries:

CREATE TABLE user_scores (
    user_id      BIGINT PRIMARY KEY,
    score        BIGINT NOT NULL DEFAULT 0,
    segment      VARCHAR(64) NOT NULL DEFAULT 'global',
    updated_at   TIMESTAMP NOT NULL DEFAULT NOW(),
    INDEX idx_segment_score (segment, score DESC)
);

Time-windowed leaderboards (daily, weekly) use separate sorted sets keyed by window:

leaderboard:daily:2026-04-17
leaderboard:weekly:2026-W16
leaderboard:global

Core Algorithm and Workflow

Score Update

Client sends POST /scores with {user_id, delta}.
API layer validates and publishes an event to a message queue (Kafka topic score-events).
Score consumer reads event, calls ZINCRBY on all relevant sorted sets (global, daily, weekly).
Asynchronously flushes the new absolute score to the relational store for durability.

Rank Query

Client sends GET /rank?user_id=9871&segment=global.
Service calls ZREVRANK leaderboard:global user:9871. O(log N) time.
Response includes rank (1-indexed) and current score.

Paginated Top-N

GET /leaderboard?segment=global&page=0&size=50
-- maps to:
ZREVRANGE leaderboard:global 0 49 WITHSCORES

Cursor-based pagination avoids rank drift between pages by anchoring to the last-seen score.

Failure Handling and Consistency

Redis failure: If the Redis primary goes down, writes queue in Kafka. On recovery, the consumer replays events to rebuild sorted sets from the relational store using a cold-start loader. Use Redis Sentinel or Redis Cluster for automatic failover.

Duplicate events: Score events carry an idempotency key (event_id). The consumer checks a processed-events set in Redis before applying a delta, preventing double-counting on consumer restarts.

Consistency model: The system is eventually consistent. Redis scores may lag the relational store by seconds during recovery, which is acceptable for leaderboard semantics. For financial or prize-critical rankings, a two-phase write (SQL commit first, then Redis update) with reconciliation jobs provides stronger guarantees.

Scalability Considerations

Sharding by segment: Each game mode, region, or cohort maps to its own sorted set on a dedicated Redis shard. Consistent hashing routes leaderboard:{segment} keys to the correct node, keeping per-shard memory bounded.

Hot key mitigation: Global leaderboards for very large user bases can exceed single-node memory. Partition into score-range buckets (e.g., >10k, 1k-10k, <1k) and merge at query time for top-N reads.

Read replicas: Route rank and leaderboard read traffic to Redis replicas. Slight staleness (milliseconds) is acceptable for display purposes.

Time-windowed expiry: Use EXPIREAT on daily/weekly sorted sets so Redis reclaims memory automatically when the window closes.

Write throughput: Kafka decouples bursty score events from Redis. Consumers scale horizontally by partition; each partition is ordered, preventing interleaving for the same user within a partition.

Summary

A leaderboard service pairs Redis Sorted Sets for O(log N) rank operations with a relational store for durability. Score updates flow through a message queue for burst absorption. Segment-based sharding, read replicas, and time-windowed keys keep the system scalable. Idempotent consumers and a cold-start loader from SQL provide resilience against Redis failures.