Design a game leaderboard

Question 1

Who submits and who looks?

Accepted Answer

The game client does both, and cannot be trusted with either — every score it sends has to be checked somewhere.

Question 2

What receives a score?

Accepted Answer

A score arriving from a phone is a claim, not a fact. A service is where that claim gets validated before it counts.

Question 3

How do you find a player’s rank among five million without counting them all?

Accepted Answer

Asking a database for a rank means ordering five million rows on every request. The usual answer is a sorted set in an in-memory store — it keeps players in score order as they are inserted, so both "top 100" and "what is my rank" are direct lookups. This is a cache used as a data structure, not as a copy of the database.

Question 4

The in-memory store restarts. Is the leaderboard gone?

Accepted Answer

Scores are the thing players care most about, so they need to be durable somewhere and the ranked set rebuilt from them. The fast structure is a working copy; it is not the record.

Question 5

Your client writes scores straight to the store. What stops a player submitting a billion?

Accepted Answer

The game runs on someone else’s phone and can be modified. Anti-cheat, rate limiting and validation all live in a service, and a direct write path skips every one of them.

Question 6

How many score submissions a second?

Accepted Answer

50,000,000 / 86,400 is about 580 a second. Comfortably small — which is worth establishing early, because it tells you the hard part here is the ranking, not the throughput.

Blueprint — system design