</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Design a Real-Time Game Leaderboard

The prompt is the most famous warm-up in system design: "Design the leaderboard for a mobile game with 50 million daily players. After every run, a player sees their global rank, the top 100, the players just above and below them, and how they stack up against their friends. There's a weekly board that resets every Monday, and an all-time one."

Most candidates have the answer ready before the interviewer finishes: a Redis sorted set, ZADD to record a score, ZREVRANK to read a rank. For one board at this scale, that answer is right, and that is the trap. The candidate who stops there never says why it's right or where it stops being right. Does a sorted set of 150 million players fit on one machine? How many operations a second can one key take before the single-threaded server that owns it runs out of CPU? What happens when two players post the same score? What happens when a retry delivers the same run twice, or when the Redis node holding the weekly board dies at 20:59 on the Sunday the season closes? And what stops someone posting 9,999,999 from a 41-second run?

The Trap Built Into a Famous Question

Two failures show up again and again:

  • The Two-Command Answer: ZADD, ZREVRANK, done in five minutes. It works on a laptop and leaves the interviewer to ask every question that matters. Signal: knows the tool, hasn't owned the system.
  • The Over-Builder: hears "50 million" and shards everything from the first minute: hash-partitioned sorted sets, a merge service, a rank cache, a stream processor. One board of 15 GB at 34,800 operations a second at peak didn't need any of it, and hash sharding turns every rank read into a fan-out. Signal: never ran the numbers.

The passing performance proves that one sorted set per board fits, and says by how much. It makes the write path safe by noticing one fact: a best score is a max, and a max doesn't care about retries, duplicates or order. It breaks ties by encoding time into the score. It keeps Redis rebuildable from a durable log. It defends a board people will try to cheat their way onto. And it names the exact point where one node stops being enough, along with the sharded design waiting behind it.

Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.