Real-Time Gaming Leaderboard System Design — Visual Journey
Watch five ranked players evolve into a production ranking architecture — trusted ingestion, Redis sorted sets, idempotent event processing, live rank-change delivery, sharding and exact-rank trade-offs, failure recovery, moderation and season rollover.
28 scenes · 28 narrated steps · interactive, self-paced
Real-Time Gaming Leaderboard
Real-Time Gaming Leaderboard
A long-form engineering design session — watch ranking, ties, Redis sorted sets, idempotent ingestion, live delivery and sharding evolve, bottleneck by bottleneck.
Maximize to view synchronized narration and navigate between explanation steps.
What You Should Understand Now
- A leaderboard ranks verified outcomes, not raw gameplay — a client-supplied score is never trusted directly; only an authenticated game server (or equivalent verification) can move a rank.
- Equal scores alone never define a unique order — FlowRank uses a deterministic tie-break (earlier achievement timestamp, then stable player ID) so the displayed ranking never flips arbitrarily.
- Redis sorted sets are an excellent baseline for bounded leaderboards, not an automatic answer to every scale problem — ZADD/ZREVRANK/ZREVRANGE have real complexity characteristics, memory costs, and hot-key limits.
- A durable, ordered event log — not the live Redis structure — is the actual source of truth; the ranking index is a materialized, eventually-consistent projection of it, with a bounded staleness contract.
- A friends-only leaderboard cannot be produced by filtering a global top-100 — it requires fetching the small eligible friend set directly and sorting only that subset.
- Splitting one massive board across shards breaks simple exact ZREVRANK — a shard-local rank is not a global rank, and exact global rank at extreme scale needs either a specialized structure or an accepted approximation.
Concepts in This Visual
Ranking Policies & Tie-BreakingRedis Sorted Sets (ZADD/ZREVRANK/ZREVRANGE)Trusted Score IngestionIdempotent Event ProcessingDurable Event Log & Materialized ProjectionRank-Around-Player & Friends LeaderboardsLive Delivery: Snapshots, Deltas & ResyncPartitioning & Hot-Key MitigationExact vs Approximate Global RankSeason Lifecycle & Moderation
Go Deeper
Complete Design
The full written walkthrough — problem, requirements, scale estimation, data model, APIs, SQL baseline, Redis sorted sets, ingestion correctness, read patterns, live delivery, sharding, seasons, and the final production architecture.
Architecture Deep Dive
Layer by layer: ranking comparators and tie-break implementation, sorted-set internals, idempotent ingestion, materialized rank projection, sharding and exact-rank trade-offs, live update protocol, season state machine, and disaster recovery.
Trade-offs & Decisions
Why Redis sorted sets beat a naive SQL index at scale (and when they don't), tie-storage strategies, delivery guarantees, partition strategy, exact vs approximate global rank, and season-reset design.
Failure & Scale Scenarios
What actually breaks in production — duplicate and out-of-order events, Redis hot keys and outages, projection crashes, feed disconnects, shard inconsistency, season rollover races, and disaster recovery.
Interview Perspective
How to structure the interview, the signals that stand out, a bank of likely follow-up questions including Staff-level ones, and a quick-reference revision sheet.