Loading…

Understanding the problem

A leaderboard ranks players by points and answers three questions: who is at the top, where am I, and who is around me. Top-K is its streaming cousin: of everything in the last hour, which items happened most, such as the most-played levels or the most-viewed videos.

This brief has both, from one game. Match results feed a season board with real prizes, which must be exact and defensible. Level plays feed a trending list, which can be a minute behind and a little approximate. Much of the design is knowing which of the two you are building at each step.

The practice brief states the requirements up front; in an interview, you would confirm them in the first few minutes. Two words carry the problem: “rank”, which must be cheap for any player, and “prizes”, which makes one list exact.

Functional requirements

CoreShow the season’s top 100 players, and any player’s rank with the 10 players just above and below them.
CoreShow how a player ranks among their friends (up to about 200).
CoreA finished match updates the player’s season total and rank within about 5 seconds.
CorePlayers with the same total are ordered by who reached it first.
CoreShow the 100 most-played levels in the last hour and in the last 24 hours, refreshed every minute; a play sent up to about 10 minutes late still counts in the hour it was played.
CoreAt the end of the season, produce the final top 1,000 for prizes.
Below the lineMatchmaking and the game itself.
Below the linePaying out prizes.
Below the lineModerating community levels.
Below the lineBoards per level, such as the fastest time on one level.The same ordered board, one per level.
Below the lineBadges and rewards for milestones.They read the board or the totals without changing how either is kept.
Below the lineDetecting cheats with models.Out of scope: limits, flags and a hold before payout are enough here.

Non-functional requirements

LatencyBoard and rank views load within about 200 ms p99.
ConsistencyThe final prize board is exactly right: every match counted once, none lost, and the result can be audited.
ConsistencyTrending may be about a minute behind and slightly approximate.
AvailabilityBoards stay fast in the last hour of a season, when views rise about five times.
AvailabilityEach region keeps showing boards if another region is down.
Below the lineA global board in step with every region.Each region keeps its own board; the global one may be a minute behind.
Below the lineExact trending counts.

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 40 million daily players, and about 80 million players on this season’s board.
ScaleAbout 300 million match results a day, about 15,000 a second at peak.
ScaleAbout 5 million community levels and about a billion plays a day, about 40,000 a second at peak; one viral level can take about 20,000 plays a second.
ScaleAbout 20,000 board views a second, about 100,000 in the last hour of a season.
ScaleThree regions; each player plays in their home region.
ScaleGame servers retry until a result is accepted; every result arrives within about 10 minutes of its match ending.

Out of scope

Out of scopeDetailed cheat detection.

Check yourself

Trending may be approximate, but the prize list may not. What does that decide?
Show answerHide answer
Where an estimate is allowed. Sketches and dropped late plays are fine for trending; the prize list is computed from a record that counts every match once.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Work out only the numbers this design depends on, with round figures and one line of working each. The surprise is that the board is small; the load is uneven.

Back of the envelope for the Online game brief

Quantity	Value	Working
Match results at peak	About 15,000 a second	From the brief: 300 million a day, about 3,500 a second on average.
Plays at peak	About 40,000 a second	From the brief: a billion a day; one viral level can take 20,000 a second.
Board memory	About 8 GB of data	80 million players × about 100 bytes, before overhead.
Board views at season end	About 100,000 a second	Five times the usual 20,000, mostly for the top page.
Trending counts in memory	About 560 MB raw	About a million levels played in an hour × 70 open minute counts × 8 bytes; closed minutes stay a day in the count store.

What the numbers tell you

The board fits in one machine’s memory, so the question is keeping it in order, not where to put it.
The write problem is one level, not the total: 20,000 plays a second on one key.
The read problem is the season’s last hour, and it is mostly one page that everyone wants.

Architecture diagramWhere the load lands

Try it: The numbers that shape the designGuided practice · Top-K and leaderboards, Online game · Senior

Check yourself

Which number rules out updating a database row per play?
Show answerHide answer
The viral level’s 20,000 plays a second. They all land on one row, which becomes a queue of locks however big the database is.

Core entities

Keep what happened apart from what is derived from it. A match result and a play are facts; a season total, the board and the minute counts are computed from them and can be recomputed, which is what makes the prize list defensible.

Two fields do more work than they look. The season total records when it was reached, because equal totals are ordered by who got there first. And each play carries when it was played, because phones send plays late.

The entities and their key fields

Entity	Key fields	Why it exists
MatchResult	`match_id`, `player_id`, points, `ended_at`	One per player per match: what prizes depend on.
SeasonTotal	`season_id`, `player_id`, points, `reached_at`, status	One per player per season; status holds a player out of prizes.
Play	`play_id`, `level_id`, `player_id`, `played_at`	One per play, with when it happened.
LevelCount	`level_id`, minute, plays	What the counting job writes.

Where each part lives

Part	Store	Why
Results and totals	PostgreSQL	They must survive failures and be read back for audits.
The season board	Redis sorted set	Read thousands of times a second, answered in about a millisecond, and rebuildable.
Plays	Kafka, copied to object storage	Tens of thousands of appends a second, only ever read added up.

Architecture diagramWhat is recorded, and what is derived

Read:Learn: Data model design Learn: Storage choice justification

Try it: Matches, plays and seasonsGuided practice · Top-K and leaderboards, Online game · Senior

Keep reading+1 min

The season in every key

Put the season id in every result, total and board key. A new season then starts empty without deleting anything, old seasons stay readable for auditors and disputes, and a recount of one season can’t touch another.

Check yourself

Why does a play carry played_at, when the server knows when it arrived?
Show answerHide answer

The API

Two facts shape this API. The top page and trending are the same for everyone, so they can be cached and shared; a player’s own rank and friends board carry Cache-Control: private, which tells shared caches not to store them (RFC 9111 (opens in a new tab)).

And points come only from game servers, which post results with service credentials and a match_id, so a retry can be recognised later. The app sends plays in batches, each with the time it was played.

The calls

Call	Request	Response	Caching
`GET /v1/seasons/{season}/top`	`limit` (up to 100)	`200` with ranked players and `as_of`	Public; shared for a second
`GET /v1/seasons/{season}/players/{player}/around`	`n` (up to 10)	`200` with the rank, points, and the players above and below	Private
`GET /v1/seasons/{season}/friends`	The signed-in player	`200` with the friends in order	Private
`GET /v1/trending/levels`	`window` (`1h` or `24h`)	`200` with levels, plays and `as_of`	Public, up to a minute
`POST /internal/v1/results`	`match_id`, `ended_at`, each player’s points	`202`; game servers only	Not cached
`POST /v1/plays`	A batch of `play_id`, `level_id`, `played_at`	`202`	Not cached

Architecture diagramWho calls what

Read:Learn: API contract design

Try it: The board and trending callsGuided practice · Top-K and leaderboards, Online game · Senior

Check yourself

Why can the top page be cached and the “around me” page not?
Show answerHide answer
The top page is the same for everyone, so one copy serves all. “Around me” is one player’s view, so a shared cache would show it to the wrong person.

High-level design

Build the design one flow at a time, following the brief: a match reaching the board, a player reading it, and a play reaching trending. The deep dives then harden each one.

A match ends and the rank changes

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

The game server posts the result. The results service records it and the player’s new total in PostgreSQL, then sets the player’s entry on the season board to the new total. The board is a Redis sorted set, which keeps members in order as their values change at O(log N) per update, and names leaderboards as a use (Redis docs (opens in a new tab)).

The trap is the obvious query. ORDER BY points sorts 80 million rows per request, and a count of the players with more points is O(rank) even with an index. How this path stays right for prizes is the third deep dive.

The game server calls POST /internal/v1/results.
The results service records the result and the new season total in one transaction.
The player’s entry on the board is set to the new total, and their new rank shows within a second or two.

Architecture diagramA match ends and the rank changes

The result and the new total are recorded, then the player’s place on the board moves. Dashed lines are asynchronous.

Diagram as text

Components: Game server (Service); Results service (Service); PostgreSQL (SQL DB); Ordered board (Redis) (Cache). Connections: Game server → Results service (POST result); Results service → PostgreSQL (result + total); PostgreSQL → Ordered board (Redis) (new total, O(log N)), asynchronous.

Read:Learn: Redis Learn: Indexes and search fundamentals

Try it: From a match to the board, from a play to trendingGuided practice · Top-K and leaderboards, Online game · Senior

Keep reading+1 min

Why a database index isn’t enough

An index on points keeps the rows in order, but a B-tree doesn’t store how many rows sit before each entry, so finding a rank still walks every row above it. A sorted set, or any order-statistic structure, keeps those counts as it goes, which is exactly what a rank needs.

Check yourself

A player around rank 30 million asks for their rank. What does the board do?
Show answerHide answer

A player opens the board

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

The top 100 is the same for everyone, so the board service serves it from a cache refreshed every second: at the peak of about 100,000 views a second, the board sees about one read a second per cache node. A player’s rank is one lookup on a read replica, O(log N) at any rank.

The app calls GET …/top and GET …/around for the player.
The top page comes from the cache, at most a second old.
The rank is one lookup on a replica, which usually trails the primary by well under a second.

Architecture diagramA player opens the board

A level is played

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

The play service appends each play to Kafka and answers at once, so nothing the player waits on writes a count. With acks=all, an acknowledged play isn’t lost while at least one in-sync replica stays alive (Kafka docs (opens in a new tab)).

A stream job counts plays per level per minute in memory and writes one count per level each minute, so the viral level costs one write a minute. The trap is a consumer that runs UPDATE levels SET plays = plays + 1 per play: the log hides the load from the app, and the viral level’s row still takes every play. Windows and late plays are the second deep dive.

The app batches plays and calls POST /v1/plays.
The play service appends them to Kafka and returns 202.
The counting job adds each play to its level’s minute by played_at, and writes the counts and top lists each minute.

Architecture diagramA level is played

Design a leaderboard and top-K

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

The season in every key

The API

High-level design

A match ends and the rank changes

Why a database index isn’t enough

A player opens the board

A level is played

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

The season in every key

04The API

05High-level design

A match ends and the rank changes

Why a database index isn’t enough

A player opens the board

A level is played

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this