System Design
04QuestionsLeaderboard

04 · Worked prompt

Leaderboard

Design rank updates, top-K queries, tie handling, seasons, and hot-partition control.
30 minInterview blueprint
INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

  1. 20pts

    Scope the problem

    0–5 min

    Prioritize the core flows, state the scale, and name the non-goals.

  2. 15pts

    Define contracts

    5–10 min

    Identify durable entities, APIs, idempotency, and the source of truth.

  3. 30pts

    Complete the diagram

    10–25 min

    Trace one write path and one read path. Label the commit boundary and async work.

  4. 20pts

    Lead one deep dive

    25–38 min

    Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.

  5. 15pts

    Prove reliability

    38–45 min

    Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design rank updates, top-K queries, tie handling, seasons, and hot-partition control.

Leaderboard · system architecture
Leaderboard system architecture. Score events are durable; partition-local ordered sets feed a versioned global top-K snapshot. Request path: Games + viewers to Leaderboard API to Score service to Score event store. Asynchronous path: Season partitions to Rank aggregators. Read path: Rank coordinator to Sorted-set index. Delivery path: Rank cache.

Write

Games + viewers enters through Leaderboard API. Score service owns validation and commits the durable record to Score event store.

Propagate

Season partitions separates the committed write from background work. Rank aggregators can retry safely while it builds Sorted-set index.

Read

Rank coordinator serves from Sorted-set index, then checks authoritative state whenever freshness, policy, or correctness requires it.

Say this first: Score events are durable; partition-local ordered sets feed a versioned global top-K snapshot.

Open the full whiteboard ↗
DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

Score events are durable; partition-local ordered sets feed a versioned global top-K snapshot.

INTERVIEW CONTRACT

Design rank updates, top-K queries, tie handling, seasons, and hot-partition control.

CAPACITY QUESTIONS TO QUANTIFY

Millions players · write bursts · low-latency top-K · deterministic ties. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

01

End-to-end walkthrough

Trace the architecture in this order.

  1. 01
    Enter and classify the request
    Games + viewers → Leaderboard API

    Score events + rank reads enters over HTTPS / RPC. Leaderboard API handles identity, admission, routing, and request context; it deliberately does not own domain truth.

  2. 02
    Validate, then cross the commit boundary
    Leaderboard API → Score service → Score event store

    Score service receives the command, checks invariants and retry identity, then uses append + CAS to update Score event store. The user-visible mutation is accepted only after this boundary succeeds.

  3. 03
    Move replayable work off the request path
    Score service → Season partitions → Rank aggregators → Sorted-set index

    Score service emits publish after commit; Rank aggregators uses consume and update rank to build Sorted-set index. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.

  4. 04
    Serve reads from the right authority
    Leaderboard API → Rank coordinator → Sorted-set index / Score event store

    Rank coordinator uses ordered seek for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.

  5. 05
    Deliver without changing the source of truth
    Rank aggregators → Rank cache → Games + viewers

    Rank aggregators uses fan-out; Rank cache returns updates over stream / push. Sequence IDs, reconnect cursors, and backpressure make delivery resumable without turning a socket into durable state.

02

Ownership ledger

Why each box exists—and what it must defend.

ComponentOwnsWhy it existsInterviewer probe
Leaderboard APIAuth + season routingIdentity, admission, routingProtects the system edge and attaches trusted context before domain work begins.Timeout budgets, quotas, regional routing
Score serviceDedupe + conditional updateWrite invariants and retry identitySerializes or conditionally applies state changes before acknowledging success.Concurrent writes, deduplication, hot ownership
Score event storeAuditable score changesAuthoritative durable stateProvides the one record used to resolve disputes, recover, and rebuild projections.Partition key, replication, consistency
Season partitionsPlayer-keyed updatesDurable asynchronous handoffAbsorbs bursts and lets slow or optional work retry independently of the request.Ordering key, lag, retention, dead letters
Rank aggregatorsLocal heaps + global mergeReplayable processingRuns expensive, fan-out, or side-effecting work with leases and bounded retries.Idempotency, poison work, autoscaling
Sorted-set indexPublished rank snapshotRebuildable query stateShapes data for the dominant reads without weakening the write-side invariant.Freshness, versioning, rebuild time
Rank coordinatorTop-K + around-meRead composition and freshness policyChooses authoritative or derived state and returns a stable client contract.Fan-out, cache policy, partial results
Rank cacheHot top-K by seasonConnection and delivery stateSeparates open connections and fan-out pressure from durable domain state.Reconnect, ordering, slow consumers
03

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage
Redis sorted sets serve live rank windows; Cassandra/Scylla or SQL stores durable score events/totals; object storage keeps snapshots.
Partitioning / sharding
Partition by board_id + hash(player_id); compute local shard top-K and merge into regional/global boards.
Indexes
Unique event_id, durable (board_id, season, player_id), sorted-set score order, and player history by time.
Replication + consistency
Score acceptance is durable/idempotent. Served rank is a versioned, freshness-bounded projection reconciled from score events.
Cache, queue + recovery
Stream score events to aggregators; cache top ranges and player-neighbor windows, never the only score copy.
Capacity math
Estimate updates/sec, reads/sec, players/board, top-K, hot tournaments, and rank freshness.
Alternative rejected
One global Redis ZSET is ideal initially but becomes a single CPU/memory owner; hierarchical top-K removes that ceiling.
04

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Partitioning

Hash players for write balance and maintain bounded top candidates per shard

Partitioning by score creates moving hot ranges
Around-me rank

Use sorted-set rank operations or approximate count summaries plus local seek

Top-K and arbitrary rank are different query shapes
Corrections

Append compensating score events and rebuild affected indexes from the log

Silent overwrites destroy auditability
05

Failure pressure test

Show detection, containment, recovery, and evidence.

Duplicate event

Deduplicate source event ID inside score update transaction

duplicate score attempts
Hot player

Serialize by player ID and rate-limit abusive sources

conflicts per player
Season rollover

Freeze old writes, create new namespace, and publish pointers atomically

cross-season writes
Before you finish, explicitly cover
  • Functional requirements and non-goals
  • Peak traffic, storage, bandwidth, and growth
  • Entities, APIs, idempotency, and pagination
  • Source of truth and consistency promise
  • Partition key, replicas, caches, and hot spots
  • Retries, backpressure, failover, and reconciliation
  • Latency, saturation, correctness, and recovery metrics
  • Security, migration, cost, and multi-region evolution
SAY THIS WHILE YOU DRAW

A four-part talk track

  1. Scope

    “I’ll prioritize update player scores at high write rates and read top-k, around-me, and friend ranks.”

  2. Scale

    “The design changes around millions players · write bursts · low-latency top-k · deterministic ties.”

  3. Decision

    “Exact global order is costly; partial candidates enable fast approximate top-K.”

  4. Risk

    “The first failure I want to pressure-test is: Hot players, ties, replay, and season rollover can corrupt rank stability.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements
  • Update player scores at high write rates
  • Read top-K, around-me, and friend ranks
  • Handle ties and seasonal resets deterministically
  • Support audit and anti-cheat correction
Leaderboard · state lifecycle
02Data model and APIs4 entities · 3 interfaces

Core entities

ScoreEventevent_id, player_id, season_id, delta, reasonOwner: Score log
PlayerScoreplayer_id, season_id, score, versionOwner: Rank service
RankEntrypartition, score, tie_key, player_idOwner: Sorted index
Seasonseason_id, rules, start, end, stateOwner: Season service

External interfaces

POST /v1/scores/events

Apply one signed idempotent score event

GET /v1/leaderboards/{season}?limit=100

Read a published top-K snapshot

GET /v1/leaderboards/{season}/players/{id}

Read score, rank, and neighbors

03Deep dives and trade-offsChoose one

Partitioning

Hash players for write balance and maintain bounded top candidates per shard

Partitioning by score creates moving hot ranges

Around-me rank

Use sorted-set rank operations or approximate count summaries plus local seek

Top-K and arbitrary rank are different query shapes

Corrections

Append compensating score events and rebuild affected indexes from the log

Silent overwrites destroy auditability
04Failures, recovery, and evidence3 scenarios

Duplicate event

Deduplicate source event ID inside score update transaction

duplicate score attempts

Hot player

Serialize by player ID and rate-limit abusive sources

conflicts per player

Season rollover

Freeze old writes, create new namespace, and publish pointers atomically

cross-season writes
05What makes the answer seniorInterviewer signals
  • Ask whether rank must be exact before choosing the index
  • Tie-breaking must be part of the key, not UI logic
  • Use an event log when corrections and anti-cheat audit matter
  • Primary trade-off: Exact global order is costly; partial candidates enable fast approximate top-K.
BEFORE THE NEXT QUESTION

Can you redraw it from memory?

  • Name the source of truth.
  • Trace the write and read paths.
  • Defend one trade-off.
  • Recover from one failure.