A leaderboard in Redis holds tens of millions of players and product now wants every player's exact global position plus deep pagination through the standings. Which parts of that stay cheap, which do not, and how would you architect around the limits?

## First, separate what actually hurts The instinct is that ranking fifty million players must be expensive. It is not — at least not the part people expect. **Rank lookup is logarithmic.** The ordered structure behind a Sorted Set stores, at each level, how many elements a link spans. Counting the elements before a given member is therefore a descent, not a walk: `ZREVRANK` is O(log N). Exact global position for one player is cheap at any realistic size. So is `ZSCORE` (O(1)), `ZCARD` (O(1)), `ZCOUNT` (O(log N)) and top-N (O(log N + N)). **Range reads by index are the expensive shape**, because their cost includes everything skipped: `ZRANGE key <start> <stop>` is O(log N + M) where M spans the *whole window from the start index*. Page 4 000 of a 50-element pager means walking 200 000 entries inside one command, during which the server serves no one else. Deep pagination is thus not a data-size problem but a **latency blast-radius** problem: one user's request degrades everyone. ### The fix: cursor pagination by score Carry the last row's score and member in the page token and query `ZRANGE key (lastScore -inf BYSCORE REV LIMIT 0 50`. Each page costs O(log N + 50) regardless of depth. Because equal scores are common on leaderboards, the cursor must include the member to disambiguate the boundary — the standard trick is to filter out members already emitted at the boundary score, or to make scores unique by packing a tiebreaker in (see below). Cursor paging is also more stable under concurrent writes: offsets shift as scores change, which makes offset paging skip and duplicate rows even when it is fast enough. ## The ceilings that actually bind **Memory.** Each member costs the member string plus per-entry overhead in two internal structures. Tens of millions of members is measured in gigabytes, and memory is the master resource: it caps how much else the instance can hold, it determines snapshot fork behaviour and copy-on-write cost, it sets replica full-sync duration, and it raises the cost of every failover. Shortening member identifiers — numeric ids rather than UUID strings — is one of the highest-leverage optimisations available and should be decided before launch. **Single-key hotness.** A Sorted Set is one key, and one key lives in one hash slot on one node. You cannot shard a single leaderboard across a cluster. A globally popular board concentrates its write traffic and memory on one node, and adding cluster nodes does not help that node at all. This is the structural limit, and every scaling strategy below is a way to avoid hitting it. **Write amplification.** Every scoring event is an O(log N) write, plus replication to every replica, plus AOF appends if enabled. A game emitting events per action rather than per match can generate orders of magnitude more writes than the product needs. Debounce in the application — accumulate in memory and flush a player's best or delta on an interval — and the leaderboard's write load becomes a design parameter rather than a consequence. ## Scaling strategies **1. Reads to replicas.** Ranks, top-N and neighbour windows are read-only and tolerate staleness of a second or two — nobody notices their rank is one refresh behind. Routing reads to replicas removes the majority of the load from the primary and is usually the cheapest large win available. **2. Time-partitioned boards.** `lb:daily:*`, `lb:weekly:*` with TTLs keep each key small and let old data expire instead of accumulating. Rollups via `ZUNIONSTORE` run on a schedule, off-peak, ideally on a dedicated instance, because a union over huge sets is one long blocking command. **3. Cohort / regional sharding.** Split the population into K boards by region, tier or a hash of the player id. Top-N per shard is cheap and a global top-N is a K-way merge of K small results client-side. Each shard is a separate key that can live on a separate node, so both memory and write load spread. **4. Approximate global rank across shards.** Merging exact ranks across K boards is not possible from per-shard ranks alone. The standard solution is a **score-bucket histogram**: maintain a second structure (a Hash or a small Sorted Set) counting how many players fall in each score bucket, updated on every score change. A player's approximate global rank is then `sum(counts of all higher buckets) + local rank within their bucket`. With buckets sized to the score distribution this is accurate to within a bucket, costs O(number of buckets) to evaluate, and is a genuinely good answer for the "you are roughly #412 000" display that no user verifies to the unit. Reserve exact ranks for the top few thousand, where users *do* check. **5. Unique scores.** Packing a tiebreaker (an inverted timestamp, or the player id's low bits) into the score makes every score distinct, which makes score-cursor pagination exact and removes the boundary-duplicate problem. The constraint is double precision: exact integers only to 2^53, so budget the bits deliberately. ## What to say out loud The complete answer names three things: the cost model (rank cheap, offset paging expensive, both bounded by one node), the ceilings (memory, single-key hotness, write amplification), and the trade you are proposing (exact ranks for the top slice, approximate ranks below it, cursor paging everywhere, replicas for reads, cohort shards when one node stops being enough). Presenting approximation as a deliberate product decision rather than a technical concession is what distinguishes a principal-level answer.