Design a gaming leaderboard

How the interviewer opens it

“Design a service that tracks player scores and standings for an online game. Players can request global, regional, and nearby-player standings. Scores change often, and players expect fast responses.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

• Population and regions
• Traffic and read mix
• Standings and nearby players
• Score updates
• Ties and membership
• Latency
• Consistency and freshness
• Durability and retention
• Availability during failures
• Deployment and exclusions

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

What interviewers ask about

Ranks and nearby players

Equal scores need one stable order. Concurrent score updates can make separately fetched ranks and nearby entries contradict each other.

Score updates across boards

Corrections can reduce scores. A failure can leave one board behind another without violating the response consistency requirement.

Recovery after data loss

The rank index can lose data after the service records progress. Seven days of events cannot restore scores from the whole season.

Query load and freshness

One global board defines ranks for every player. More query capacity must not break exact ranks or hide stale results.

Common mistakes

• The design stores each player's rank and rewrites many ranks after one score update.
• The design uses a score interval to find nearby players, despite uneven score gaps and ties.
• The service keeps only the top players when it must return every player's rank.
• The service ignores duplicate updates, delayed corrections, or revision order.
• The recovery plan cannot restore older acknowledged scores after a zone failure and event expiry.
• The design partitions players before it explains how the service computes exact global ranks.

The bar by level

Mid-level (L4/E4)

Defines ties and nearby results. Selects an index that supports exact rank queries. Handles duplicate requests and defines durable acceptance.

Senior (L5/E5)

Makes each response internally consistent. Handles delayed corrections and partial updates across boards. Defines freshness limits and restores acknowledged scores after a zone failure.

Staff (L6+/E6+)

Validates capacity and recovery time with numbers. Proves recovery remains possible after event expiry. Explains exact ranks across partitions and equal-score concentration.