Design a Real-Time Leaderboard

Social, Feed & EngagementMediumdesign-leaderboard

Design global and per-segment rankings that update live for millions of players, answering both 'top 100' and 'what is my rank' without scanning the whole set.

Sorted SetsApproximate RankingTime-Windowed BucketsSharded Aggregation

Traffic & Capacity Estimates:

100M ranked players · 1M score updates/second · rank query under 20ms

Functional Requirements

•Update a player's score and reflect it in rank ordering within seconds.
•Return the top N globally and within a segment (country, guild, friends).
•Return an arbitrary player's exact or approximate rank and their neighbours.
•Support daily, weekly, and all-time windows that roll over cleanly.

Non-Functional Requirements

•Top-N and rank-of-user queries under 20ms at p99.
•Score updates must not be lost during a cache node failure.
•Rollover of a time window must be atomic from the user's point of view.

Back-of-the-Envelope Math

100M players in a Redis sorted set is roughly 8-10 GB — single-node feasible, but a single-node bottleneck.
1M updates/second exceeds one Redis instance, forcing sharding by score range or by segment.

Key Architectural Trade-offs

A single sorted set gives exact ranks and does not shard cleanly; range-sharded sets scale writes and make global rank an aggregation across shards.
Exact rank for every player is expensive at 100M scale; bucketed approximate rank ('top 3%') is cheap and usually what the UI needs.
In-memory ranking is fast and volatile — a durable score store plus periodic rebuild is the price of surviving a cache loss.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow