Counters & leaderboards

A daily word puzzle has 2 million players. Each day's puzzle shows how many people solved it and how many liked it, and a leaderboard ranks the day's fastest solves. The first version stores the like count as a number on the puzzle's row and adds one on every press. On a normal day, likes arrive a few at a time. The morning a celebrity shares the puzzle, they arrive at 400 a second, all to the same row.

That one row now behaves like any hot key (Hot partitions & skew): every increment waits for the one before it, and the row's limit becomes the feature's limit. Some databases state the limit outright. A single Firestore document can't be updated at an unlimited rate; a counter shard there is sized for about one increment a second. At 400 likes a second, a single-document counter is about 400 times over budget.

Three different problems hide in "just count it":

• Correctness: a like must count once, even when the app retries, and an unlike must remove it.
• Write load: popular items concentrate writes on one key.
• Ranking: a top-ten list, and "you are 48,212th", must be answered for millions of players without sorting on every request.

An increment is not idempotent. An atomic counter, DynamoDB's for example, increments again on every call, so a retried request overcounts. A like button retried after a timeout, a double tap, or a client that resends after reconnecting all add a second like from the same person, and an unlike can't tell which increment to undo.

The fix is to store the fact, not just the number. A like is a row keyed by (puzzle, player), so the database itself refuses a duplicate, and an unlike deletes that row. The count is derived from those rows. Kept that way, the counter can be wrong, late or lost, and it can always be recomputed:

Most social counts are shown rounded anyway, as "12K likes", so a number a few seconds behind is invisible to players. That tolerance is what makes the next section possible: if the number can lag, the writes that maintain it can be batched.

The like rows themselves spread across many keys, one per player, so they aren't hot. Only the derived total is. Rather than incrementing it on every like, each application server keeps a small in-memory tally per puzzle and flushes the sum once a second:

Splitting is the distributed counter: the count is the sum of several shard documents, each incremented by a random writer. The trade-off is this. Write throughput grows linearly with shards, so 10 shards take 10 times the writes; but reading the count means reading every shard, so reads get slower and more expensive as shards are added. Its suggested fix is a separate roll-up document that holds the total, updated at a slower cadence, which clients read instead.

An in-memory store is the other common home for counters. Redis increments are atomic and O(1) in memory, and a counter, one INCR per event, is the most obvious use of them. The cost is durability: treat a Redis counter as the fast copy, flushed to the database or rebuilt from the like rows (In-memory data-structure stores).

The daily leaderboard needs three answers fast: the top ten, a player's rank, and the players just above and below. A database query that sorts 2 million results for every request does far too much work; what's needed is a structure that keeps scores ordered as they arrive. Redis's sorted set is the standard tool: unique members, each with a score, kept in order by a skip list alongside a hash table, so adding or updating a member costs O(log N):

Each operation stays cheap as the board grows. Looking up a rank is O(log N); reading a range is O(log N + M) for M entries. For 2 million players, log₂ 2,000,000 ≈ 21 steps, instead of sorting 2 million scores. The LT flag on ZADD only updates a score if the new one is lower, so a player's best time sticks without a separate read.

The sorted set's rules have consequences worth knowing:

• Ties sort by member name. When two members have the same score, Redis orders them lexicographically, so player:1234 beats player:9876 on an equal time. To break ties by who finished first, fold the finish time into the score at a smaller scale: the solve time in tenths × 10^10, plus the finish timestamp in seconds. The time always decides, and the timestamp only separates equal times.
• Direction is a choice. Lower is better for solve times, so ZRANGE from 0 lists the fastest. For points, where higher is better, use the reverse range and reverse rank.
• Time windows are separate keys. A key per day, week or season, with an expiry, so old boards drop out on their own.

The leaderboard is still derived data. Each solve is first recorded as a result row, and the sorted set is updated after; if the set is lost, it's rebuilt from the day's results. That also handles cheating: a disqualified score is deleted from the results and removed from the set with ZREM.

A sorted set lives on one Redis node, and every score update for the day goes to that one key. For a single daily board of 2 million players that's comfortable. A global all-time board with hundreds of millions of members, updated by every game, is not: the key is hot and large at once.

Two observations make big boards manageable. The top of the board is small and heavily read, so it can be kept exactly and cached. Players far down rarely need an exact number: "48,212th" and "top 3%" mean the same to them. So large boards often combine three parts:

Counting the most-played or most-liked items over a moving window, "trending today", is a different problem: there are too many items to keep a counter each in memory. That's the job of approximate top-K structures (Count-Min Sketch & top-K).

For the puzzle game, and most apps with counts and rankings: