Real-Time Leaderboard
mediumOpen designCommonly asked~30 minHLD roundPhone screenSDE-2 and upAmazonGoogleMetaMicrosoftFlipkartRazorpayStorage & Data ModellingCachingStreaming & Real-time DataCapacity & Estimation
The question, as asked
“Design the leaderboard for a game with 50 million players. Everyone wants to see the global top 100 and their own rank, live.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- Is it a single global board, or per-region, per-friend-group, per-season? Multiple boards multiply the write cost, because every score update touches each board it belongs to.
- How 'live' is live? Top-100 refreshing every few seconds is very different from every score update appearing instantly.
- Does every player need an exact rank, or is 'top 2%' acceptable below the top? This single answer changes the design more than anything else.
- Score semantics: highest ever, cumulative, or a rolling window? A time window means scores expire, which is a much harder structure than a monotonic total.
- Scale: score updates per second at peak, and leaderboard reads per second. Reads will outnumber writes heavily — confirm that, because it justifies caching the top-N aggressively.
- Tie-breaking rules. Two players on the same score need a deterministic order, or the board visibly reshuffles between refreshes and users file bugs.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.