Design a Real-time Gaming Leaderboard System — System Design Interview Practice

Interview prompt

Design a low-latency gaming leaderboard that ingests authoritative score events, serves global and friend rankings, and reflects changes within seconds for millions of players.

• Define an authoritative score-event contract, idempotency key, and tie-breaking rule for global, regional, season, and friend scopes.
• Partition hot leaderboards, use materialized top-K views, and explain how late, duplicate, reordered, and corrected scores are handled.
• Keep score submission durable and asynchronous while serving low-latency reads from sharded ranking stores.
• Explain anti-cheat validation, replay/rebuild, rank accuracy, failover, freshness indicators, observability, and degraded reads.

Requirements and scale assumptions

• Accept authenticated score events, deduplicate them, update a player's score, and expose rank, neighbors, and top-K results.
• Support global, regional, season, and friend-only leaderboards with an explicit freshness or provisional-result marker.
• Allow score corrections, season resets, player privacy, replay from durable events, and recovery after a ranking shard fails.
• Meet p95 read latency under 10ms and reflect committed events within a few seconds under normal load.
• Scale to millions of concurrent players and bursty match results without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• Millions of active players, with bursts of 100k score events per second during tournaments
• Partition by leaderboard scope and shard hot global boards; maintain friend lists separately from score indexes.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 100k score events/s peak — Peak ingestion drives event partitioning, buffering, and backpressure.
• Latency target: p95 reads < 10ms; updates visible < 5s — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — The durable score-event log is authoritative; ranking indexes are rebuildable projections.
• Async boundary: At-least-once workers — Keep ElastiCache Redis for in-memory leaderboard, Redis Sorted Sets for rankings, Lambda for score updates off the synchronous path.

Key entities

• InteractioninteractionId, actorId, objectId, type, version, occurredAt

  Canonical real time gaming leaderboard system interaction with an idempotency key and ordering version.

• ConnectionSessionsessionId, userId, deviceId, roomKey, lastHeartbeat, status

  Ephemeral but observable real time gaming leaderboard system connection registration used for routing and presence.

• FanoutCursorstreamKey, shard, offset, consumerGroup, updatedAt

  Durable progress marker for real time gaming leaderboard system fan-out and replay.

• DeliveryReceiptinteractionId, recipientId, channel, attempt, status, deliveredAt

  Deduplicated real time gaming leaderboard system delivery state for reconnects, retries, or acknowledgements.

Data flow

1. 1. Accept and commit the interactionThe real time gaming leaderboard system gateway authenticates the actor, validates room or object membership, applies rate limits, and conditionally commits the interaction.
2. 2. Publish an ordered eventAn outbox emits the committed real time gaming leaderboard system transition with an event ID, partition key, sequence, and replay retention.
3. 3. Fan out by partitionConsumers route real time gaming leaderboard system events to connected recipients, durable inboxes, or notification channels without making the origin write wait for every recipient.
4. 4. Resume and reconcile connectionsClients reconnect with a cursor; the real time gaming leaderboard system service replays missed events, deduplicates delivery, and exposes stale or degraded state.
5. 5. Measure latency and recoverOperations tracks real time gaming leaderboard system publish-to-deliver latency, hot partitions, reconnect storms, dropped events, and consumer lag for replay or repair.

Deep dives and trade-offs

• Ordering, idempotency, and hot keysChoose a real time gaming leaderboard system partition key that preserves required order while distributing high-volume rooms, users, or objects. Use event IDs, inboxes, consumer offsets, and conditional state transitions for at-least-once delivery. Split or isolate hot partitions without changing the client-visible sequence contract.
• Reconnect and replay semanticsIssue resumable real time gaming leaderboard system cursors with an expiry and a clear snapshot-plus-delta fallback. Bound replay windows and rebuild from durable state when a cursor is too old. Expose version and freshness so a client can distinguish current, catching up, and degraded state.
• Backpressure and presenceKeep connection heartbeats and ephemeral presence separate from durable real time gaming leaderboard system interactions. Coalesce safe updates, shed low-value work, and protect critical events during reconnect storms. Measure end-to-end delivery, not only broker publish latency.
• Direct fan-out versus pull-based readsUse push for latency-sensitive real time gaming leaderboard system deltas and pull or replay for reconnect, history, and recovery. A push-only design loses state when clients disconnect and a pull-only design wastes latency and bandwidth.
• Per-recipient queues versus shared streamsUse shared partitioned streams with per-recipient cursors where fan-out is large, and isolate exceptional high-fanout objects. A queue per recipient becomes expensive and hard to inspect at large scale.
• Strong ordering versus availabilityGuarantee ordering only within the scope the product needs, such as a room, object, or conversation. Global ordering introduces a bottleneck and still does not solve duplicate delivery or reconnect recovery.