Problem Statement: A Social Gamification and Leaderboard Platform
Frames the product as a real-time competitive scoring engine with social graph integration, not a simple CRUD app.
Problem statement
Design a social games and leaderboard platform that lets users compete in mini-games, track activities (steps, quizzes, challenges), earn points, unlock achievements, and view real-time leaderboards scoped to friends, leagues, or global rankings.
The system must ingest high-velocity score submissions, compute rankings across millions of players, maintain social graph relationships for friend-scoped boards, trigger achievement notifications on milestone crossings, and resist score manipulation—all while keeping leaderboard reads under 50 ms p99.
This is not a conventional web application. A leaderboard is a continuously sorted projection over a high-write stream. Every score submission potentially changes the rank of thousands of players below the submitter. The read path ("show me my rank and the top 100") is 100x the write path, but writes must be atomically ordered to prevent rank inversions.
Why the problem is distinctive
A social feed can tolerate eventual consistency—a post appearing 2 seconds late is invisible. A leaderboard cannot tolerate rank inversions: if Alice scores 1500 and Bob scores 1490, Alice must appear above Bob on every subsequent read. This demands atomic compare-and-swap on scores, or an append-only event log with deterministic replay.
The social dimension adds a second axis: friend leaderboards require intersection queries between the global ranking and a user's social graph. With an average of 300 friends per user and 10M DAU, naive per-read graph traversal is infeasible. Pre-computation, caching, or probabilistic structures are required.
The four architectural planes
- Ingestion plane: score events, game sessions, activity telemetry. High write throughput, at-least-once delivery, idempotent processing.
- Ranking plane: sorted data structures, rank computation, sharding strategy, consistency guarantees.
- Social plane: friend graphs, league membership, scoped leaderboard queries.
- Reward plane: achievements, badges, streaks, notifications, anti-cheat adjudication.
A strong answer keeps these planes separate. The ranking plane must never block on the social plane. The reward plane must never gate the ingestion plane.
Public operating baseline
Duolingo reports 100M+ MAU with league-based XP competition driving 2.4x retention. Peloton's live leaderboard supports 100K+ concurrent riders per class. Strava processes 120M+ activities annually with segment-based KOM/QOM leaderboards. These are cited public figures for context.
For capacity planning, this answer assumes: 10M DAU, 2M peak concurrent players, 500K score submissions/sec at peak, 5M leaderboard reads/sec, 50 tracked games/activities, 300 average friends per user. All uncited values are stated design assumptions.
Key Highlights
- •Leaderboard reads are 10x the write path but writes must be atomically ordered to prevent rank inversions.
- •Friend-scoped boards require intersection queries between global rankings and the social graph.
- •The architecture has four planes: ingestion, ranking, social, and reward.
- •Public figures (Duolingo 100M+ MAU, Peloton 100K concurrent, Strava 120M activities) provide context; all scale targets here are explicit assumptions.
- •A stale leaderboard read is acceptable; a rank inversion is not.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate the ingestion path from the read path because their consistency and latency requirements differ fundamentally."
- "Before choosing data structures, let me define what rank correctness means for this product."