Mock Interview Examples

Design a leaderboard system for a large-scale multiplayer mobile game with a global player base. Take it wherever you think is most important — feel free to ask me any clarifying questions before you start.

Thanks. Before I design, a few questions to make sure I'm solving the right problem. First — what leaderboard scopes do we need? Just global, or also regional, friend, and guild?

Global is required. Friend leaderboard is a nice-to-have. Let's include regional too.

Got it. Can scores decrease, or only increase? And is the leaderboard tracking personal best, current score, or a cumulative total?

Scores can only increase. The leaderboard tracks personal best — highest score ever achieved.

Good — that simplifies writes a lot since most updates will be no-ops. Last two: do we need daily/weekly/all-time windows? And when a player finishes a match, do they need to see their exact rank immediately, or is a movement signal acceptable — "you moved up ~200,000 spots"?

Yes to time windows — daily, weekly, all-time. On rank: players care about seeing movement. Exact rank is less critical.

Perfect. So functional requirements: global, regional, and friend leaderboards; personal best scoring, scores never decrease; daily/weekly/all-time windows; approximate rank with movement signal after each match.

For scale: I'll assume 100M registered players, ~10M daily active. Score updates happen after each match — peak maybe 500k updates/sec. Reads are heavier — players check leaderboards frequently, probably 2–3x write volume.

On consistency: since scores only increase, a few seconds of staleness on rank is acceptable. Availability over consistency. P99 read latency target: under 100ms.

What about the friend leaderboard — same staleness tolerance?

Friend leaderboards need tighter consistency — players know each other personally, they'll notice stale data. I'd target a few seconds lag at most and prioritize accuracy over perfect freshness there.

Core entities: Player — player_id, display_name, region_id. Score — player_id, personal_best, last_updated. FriendRelation — player_id, friend_id, symmetric. Leaderboard — scope, time_window, ordered list of player+score.

The score entity is the source of truth. The leaderboard is always a derived view — never written to directly, always computed from scores.

Good distinction. How does the friend relation affect leaderboard design?

Friend leaderboard is a personalized view — each player has their own ranked list of friends. The social graph determines which scores to include, but the scores come from the global score store. I'll cover the fan-out strategy in the deep dive.

Four key endpoints. POST /scores — body: player_id, new_score. Updates personal best if higher, triggers downstream leaderboard updates, returns rank delta.

GET /leaderboard/{scope}/{window} — scope: global/regional/friend, window: daily/weekly/alltime. Paginated top-k with ranks.

GET /leaderboard/{scope}/{window}/me — requesting player's rank plus nearby players ±5.

GET /leaderboard/friend/{window} — friend leaderboard for requesting player.

The POST is write path; GETs are read path. They'll have very different performance characteristics.

Write path: Score update hits the Score Service, which checks personal best against a Redis hash. If the new score beats it, write to PostgreSQL first — source of truth — then publish a ScoreUpdated event to Kafka. Three consumers handle this asynchronously: Global, Regional, and Friend leaderboard consumers. This decouples the write spike from Redis and makes each leaderboard type independently scalable.

Storage: Redis sorted sets are the core — ZADD for writes, ZRANGE for top-k, ZREVRANK for exact rank. One sorted set per scope + window combination. PostgreSQL stores personal bests as the durable source of truth.

Read path: The Leaderboard Service serves all reads. Top-k hits Redis directly, cached with a short TTL. "My rank" uses a score histogram for approximate rank. Friend leaderboard merges a per-user cached sorted set with live fetches for high-degree users — I'll detail this in the deep dive.

Time windows: Each window is a separate sorted set. Daily and weekly keys carry TTLs aligned to the boundary.

How do daily and weekly resets work exactly?

Each time window is a separate key. Daily TTL is ~25 hours, weekly ~8 days. When a score updates, the consumer writes to all three windows. The all-time window only updates if it's a new personal best; daily and weekly always update since they track best score within the window. At reset, the old key expires and a new one starts accumulating. Before expiry, a background job can snapshot the top-k to cold storage for historical records.

Let's go deeper on rank. How does a player see their rank after the match? They have 100M other players in the system.

This is where the problem diverges from top-k. ZREVRANK gives exact rank in O(log N), but at 100M players on a single node, millions of concurrent rank queries plus constant writes makes this a hot key problem.

My solution is a score histogram with a prefix sum array. Since the game has bounded discrete scores — say 0 to 10,000 in multiples of 50 — I have 200 fixed buckets. Each bucket stores a count of players in that score range. I maintain a prefix sum over those counts, recomputed every few seconds by a background job.

Approximate rank becomes a single array index read — O(1) from application memory, no Redis query needed. Error is bounded by bucket size. For rank movement delta: snapshot prefix_sum before and after the score update, return the difference.

You mentioned sharding. How would you shard the sorted set?

Range-based sharding by score, aligned with the histogram bucket boundaries. 4 shards covering 0–2500, 2501–5000, 5001–7500, 7501–10000. Since we know the score distribution from game mechanics, I'd use equal-frequency boundaries so each shard holds roughly the same number of players.

Global rank = sum of ZCARD for all shards above mine — O(1) from cached bucket counts — plus ZREVRANK within my own shard at O(log N/shards). The bucket counts I already maintain for approximate rank double as shard cardinalities. These two systems reinforce each other.

What about the friend leaderboard?

The key insight is the fan-out decision is made from the writer's perspective based on their friend count, not the reader's.

Normal users below a threshold — say 500 friends — fan out on write. When their score updates, the Kafka consumer writes their new score into each friend's cached sorted set. Reads are O(1).

High-degree users above the threshold skip fan-out. Their score lives only in the global sorted set. When any user opens their friend leaderboard, normal friends' scores come from the per-user cache, high-degree friends' scores are batch-fetched via ZSCORE from the global set, and the merge happens in application memory.

Friend add/remove: for fan-out-on-write users, immediately update both users' cached sorted sets. The friend list itself is cached separately from the graph DB.

How do you handle a Redis shard going down?

With replicas, the leaderboard continues to be served — reads fall back to replicas, which are slightly stale but acceptable. Writes buffer in Kafka during failover, so no score updates are lost within the Kafka retention window — I'd set that to at least 24 hours.

Redis Sentinel handles primary re-election automatically. If the entire shard is lost, a background job bootstraps the new node from PostgreSQL — batch SELECT scores within the shard's score range, ZADD in pipelines. Then replay Kafka events to catch up writes that arrived during recovery. This takes 10–30 minutes depending on shard size.

During that window, the affected score range can't be served — that's a real service interruption. The mitigation is replicas in separate availability zones so the probability of all copies being lost simultaneously is very low.