Real-Time Gaming Leaderboard System Design Interview Guide

With the original FlowRank board — Ava 9,800 (#1), Ben 9,500 (#2), Chloe 9,500 (#3), Dev 9,100 (#4), Eli 8,700 (#5) — top-N is a single range query against a structure that's already sorted by the full ranking key (score, then tie-break fields), not a per-request ORDER BY scan over the full player table. A Redis sorted set with ZREVRANGE is the canonical mechanism, returning the top N members in O(log N + M) where M is the number requested.

• What if two players have the exact same score — does ZREVRANGE alone break the tie correctly? — Not by itself — a raw Redis sorted set breaks ties by member name lexically, which isn't FlowRank's rule. The real score stored in the sorted set has to encode the full tie-break key (score, then inverted timestamp, then player ID) into one comparable value so the structure's native ordering already matches the product's deterministic rule.

A direct rank lookup by player ID, not a scan of the whole board — ZREVRANK against the sorted set returns the 0-indexed position directly. Using Test A's post-event board (Ava #1, Dev #2, Ben #3, Chloe #4, Eli #5), looking up Dev's rank should return exactly #2 in O(log N), independent of total player count.

• Does this requirement change if you need an exact global rank across many shards? — Yes — a single-node sorted set gives an exact rank for free; once the board is sharded for scale, exact global rank requires merging per-shard counts, which is a materially harder problem covered in the staff-level section.

First get the player's rank via ZREVRANK, then fetch an inclusive window of rank - radius to rank + radius via ZREVRANGE. Test F: from the original board, Chloe (radius 1) returns Ben (#2), Chloe (#3), Dev (#4) — a 3-player inclusive window centered on Chloe.

• What happens if the player is near the very top or bottom of the board? — The window simply clamps — a radius-1 request for Ava (#1) returns only Ava and Ben, since there's no rank #0; the API contract should explicitly define this as a clamped, not an error, response.

You cannot filter a global top-100 result and hope friends appear in it — most friends won't be in the global top-100 at all. The correct approach is fetching each friend's score directly (by player ID) and sorting that specific subset server-side. Test E: Ava's friends are Ben, Dev, Eli; from the original board, the friends-only ranking among just those three is Ben #1 (9,500), Dev #2 (9,100), Eli #3 (8,700) — explicitly a friends-subset rank, not their global rank. Ben's global rank is #2, but his friends-rank here is #1.

• Where does the friends list itself come from? — A separate social-graph service, assumed to already exist and be queried by the leaderboard service — the leaderboard doesn't own friend relationships, it only consumes a friend-ID list to drive a multi-get-and-sort operation.
• Does this scale if a player has thousands of friends? — A multi-get of thousands of scores followed by an in-memory sort is still cheap relative to a full-board scan, but it's a real cost that should be named rather than assumed away for an unusually social player.

FlowRank's policy: highest verified score wins; ties broken by earlier achievement timestamp, then stable player ID ascending. This produces a deterministic unique ordering — every player gets a distinct rank number (1, 2, 3, ...) — never competition ranking (1, 1, 3, where tied players share a rank and a gap appears after) and never dense ranking (1, 1, 2, no gap). Test B makes this concrete: from the original state, Eli reaches 9,500 at 10:06:00. Ben stays #2 (9,500 @10:01), Chloe stays #3 (9,500 @10:02), Eli is #4 (9,500 @10:06 — the latest of the three ties), and Dev drops to #5 (9,100, now behind all three tied 9,500 scores). All three of Ben, Chloe and Eli have the exact same score and are ordered purely by achievement timestamp.

• Why not just use whichever score event arrived at the server first? — Arrival order at the server can be affected by network jitter and retries; the achievement timestamp (when the score was actually earned, assigned by the trusted game-server pipeline) is the fair, deterministic tiebreaker — not receipt order.
• What if two players achieve the identical score at the identical timestamp? — That's exactly why player ID is the third-level tiebreaker — it guarantees total determinism even in a timestamp-collision edge case, since no two players share an ID.

A sorted set keeps all members ordered by score with O(log N) insertion, rank lookup, and range queries — exactly the operation profile a leaderboard needs for top-N, player-rank, and rank-around-player. The real limit: a sorted set lives entirely in memory on (practically) one node's data structure, so a board with hundreds of millions of members has real memory-footprint and single-node-throughput implications, and tie-breaking requires encoding the full comparator into the stored score rather than relying on the raw score field alone.

• Is Redis the source of truth, or a derived view? — A derived, fast read-and-rank view — the authoritative record is the score event, and the sorted set is rebuildable from it; losing the sorted set is an availability problem, not a data-loss problem, as long as the event log survives.

These are three distinct comparators, not one universal rule. Highest-score mode keeps a player's best verified score and compares higher-is-better. Cumulative mode (Test J) sums event values over time: three events arrive — +100, +50, and a duplicate of the +50 event (same event ID) — the correct total is 150, not 200, because duplicate detection by event ID prevents double-counting; this is idempotent summation, not a "keep the higher value" comparison, which is a highest-score-mode-only rule. Fastest-time mode (Test K) ranks ascending — a lower completion time is better and ranks higher — with its own explicit tie policy; this is not the same comparator direction as highest-score mode, and assuming one universal "bigger number wins" rule across modes is a real bug.

• Can one player appear on leaderboards in multiple modes at once? — Yes — each mode/scope combination (e.g. Arena Clash solo highest-score global, vs. a separate speedrun fastest-time board) is its own independent ranked structure with its own comparator; they don't share state.
• Does idempotent summation in cumulative mode ever need a 'best attempt' semantics instead? — That would actually be a different, highest-single-value policy applied per event rather than a running sum — naming which one a given leaderboard mode uses is a required product decision, not something to assume.

The leaderboard system doesn't re-derive anti-cheat logic itself — it trusts a score event only if it arrives from the authoritative, already-verified game-server/anti-cheat pipeline, carrying a durable event ID and an achievement timestamp. A client directly POSTing an arbitrary score to the leaderboard API, bypassing that verified pipeline, should be rejected or routed through verification first — the leaderboard's correctness depends entirely on the integrity of what it's handed.

• What if verification is itself slow or asynchronous? — The leaderboard should either hold the score unranked until verification completes, or (if the product wants provisional display) clearly mark it as provisional — silently ranking an unverified score as if it were final is a correctness risk the design should name explicitly.

Every score event carries a unique, durable event ID; applying an event is idempotent on that ID — if the same event ID is seen again, it's a no-op. Test C: reprocessing evt-101 (Dev's verified 9,700 from Test A) a second time has zero additional effect — Dev's score and rank stay exactly as Test A left them (9,700, rank #2).

• Where does deduplication actually happen — producer or consumer side? — Consumer-side, at the event-application step — you can't fully rely on an upstream producer never retrying, so the projector itself must check "have I already applied this event ID" before mutating any ranked state.

For highest-score mode, a new event only updates the stored best score if its value actually improves on the current best for that player — delayed delivery of an older, lower score is a safe no-op rather than an overwrite. Test D: after Test A (Dev's best is 9,700, rank #2), a late/delayed Dev event carrying his older 9,200 score arrives — it's rejected as a no-op because 9,200 is less than the current best of 9,700. Dev's best stays 9,700 and his rank stays #2; nothing is overwritten.

• Does this conditional-update rule apply to cumulative mode too? — No — cumulative mode doesn't compare values at all, it adds them exactly once per unique event ID (Test J); applying the highest-score-mode 'compare and keep higher' rule to cumulative mode would silently drop legitimate additions, which is a real cross-mode bug to avoid.

Score application for one player must be processed with a single logical order (e.g. per-player event ordering, or a compare-and-set style conditional update keyed on current best), so two near-simultaneous updates for the same player don't race into an inconsistent final state. Whichever update is applied last must still respect the highest-score-mode comparison rule — the final stored value is always the true maximum of everything seen, regardless of arrival order.

• Does this require locking the player's record? — Not necessarily a traditional lock — an atomic conditional update ("set score to X only if X is greater than the current stored score") achieves the same correctness without a separate lock/unlock step, and is the more common real-world mechanism.

Leaderboard reads (viewing top-N, checking your own rank) happen far more often than score-submission writes, and a full or even indexed ORDER BY scan repeated on every page view doesn't scale to real-time, high-read-volume traffic — especially for rank-around-player and exact-rank queries, which need an efficient position lookup, not just a sorted page. The right split is a relational (or durable) store for the authoritative score history and reporting, plus an in-memory sorted structure (Redis sorted set or equivalent) maintained as a fast, continuously updated ranked view for the hot read path.

• So is the database still involved at read time at all? — Rarely on the hot path — it's the source of truth for score history, audits, and rebuilding the ranked view from scratch, not the thing directly answering every leaderboard page view.

A push mechanism — Server-Sent Events or WebSockets — notifies connected clients of relevant rank changes (their own rank moved, or a top-N change) as they happen, instead of every client re-polling on a fixed interval regardless of whether anything changed. The projector that updates the ranked view is also the natural place to emit these change notifications.

• Does every rank change need to be pushed to every connected client? — No — only to clients for whom it's relevant (their own board view, or a top-N they're currently watching); pushing every global mutation to every connection doesn't scale and isn't useful to most of them.

The client doesn't get a full re-fetch by default, nor does it silently jump straight to the latest state — it requests a contiguous delta replay from its last-known board version forward. Test I: a client's last-applied board version is 42, and the server is currently at version 46 — the client requests versions 43 through 46 as a contiguous delta replay, not a full re-fetch of everything and not silently skipping straight to 46.

• What if the gap is too large to replay efficiently (client was offline a long time)? — The server can fall back to a fresh full snapshot plus the current version number when the delta gap exceeds a reasonable bound — but this is an explicit fallback decision, not the default behavior for an ordinary short reconnect.

Because the ranked view (sorted set) is a derived projection and the score-event log is the source of truth, rebuilding means replaying the event log in order, through the same idempotent, comparator-aware application logic, into a fresh structure — the same mechanism used for ordinary incremental updates, just run from the beginning (or from the last good snapshot).

• Does this rebuild need to pause live traffic? — Not necessarily if done against a separate structure that's swapped in once caught up (a blue-green rebuild) — pausing live reads/writes during a full rebuild is a simpler but more disruptive alternative, and which one you choose is a real trade-off to state explicitly.

A correction is applied through the same event pipeline, as an explicit, audited event that invalidates or revises the prior score — never a silent in-place edit of the ranked view alone. Test G: from the original state, Ava's 9,800 score is invalidated by moderation; since she has no earlier valid score on record, she becomes fully unranked, not just demoted. The rest shift up exactly one position: Ben #1, Chloe #2, Dev #3, Eli #4.

• What if Ava did have an earlier valid score on record? — She'd fall back to that earlier score and be re-ranked accordingly, rather than being removed entirely — removal from the board only happens when there's no remaining valid score to rank her by.

Test H: when season S7 is finalized, it becomes immutable, and a new, empty S8 opens for fresh ranking. A late-arriving S7 event must not be silently applied to either board — not to S7 (already finalized and closed to writes) and not to S8 (the wrong season entirely). If that event is ever allowed to count, it requires an explicit, audited correction process, not an automatic application to whichever season happens to be currently open.

• Why not just keep S7 open a little longer to absorb stragglers? — Because 'a little longer' isn't a bound — there needs to be a hard, stated cutoff after which S7 is truly closed, otherwise season-end payouts, snapshots, and rankings can never be treated as final with confidence.

Because the ranked view is a projection updated asynchronously from the authoritative event log, there's an inherent, bounded propagation delay between "score accepted" and "rank visibly updated." This is acceptable as an explicitly stated trade-off — a bounded staleness window, not unstated eventual consistency and not a false claim of zero-latency real time.

• What would make this unacceptable? — An unbounded or unmonitored staleness window — the design needs an observable lag metric and an alerting threshold, so 'a few hundred milliseconds, usually' doesn't silently become 'sometimes minutes' without anyone noticing.

Top-N and rank-around-player reads are naturally cacheable for short windows since they change relatively slowly in aggregate even under high write volume — a short-TTL cache in front of the sorted-set reads, plus horizontally scaled read replicas of the ranked view, absorbs the bulk of read traffic without touching the authoritative write path.

• Does this caching conflict with the 'real-time' requirement? — Only if the cache TTL isn't chosen consistently with the already-stated bounded-staleness contract — the cache's staleness window should be a known, small addition to the existing projection lag, not a separate unstated delay.

Not for free. A single-node sorted set gives exact rank trivially; once the board is partitioned (by hash of player ID, or by region), each shard only knows ranks within itself. An exact global rank requires either merging per-shard counts (how many players in every other shard score higher than this player — an aggregation across all shards on every rank query) or maintaining a separate, more expensive global-merge structure kept in sync with the shards — both add real latency or staleness cost compared to a single-node answer.

• Is there a cheaper alternative if exact rank isn't truly required? — An approximate rank (e.g. a percentile bucket, or a rank accurate within a known small error bound) is far cheaper to maintain across shards — this needs to be an explicit product trade-off, not a silently approximated answer presented as exact.

A single sorted-set node has a throughput and memory ceiling; beyond it, you need partitioning (by player-ID hash shard, or regional boards that roll up periodically), accepting that partitioning complicates exact global rank as discussed above. The honest framing: pick the partitioning scheme based on which query pattern (top-N, player rank, rank-around-player) you must keep fast and exact, and name which of those becomes approximate or higher-latency as a direct consequence.

• Does sharding by score range instead of player ID help? — It can make top-N trivial (the top shard holds the highest range) but creates severe hot-shard skew at the top of the distribution where most read traffic concentrates — a real trade-off to name, not a free win.

State it precisely: a score-submission write is acknowledged as accepted only after the event is durably recorded in the authoritative event log (not merely after the in-memory ranked view is updated) — so a crash after the ack can never lose the underlying fact that the score was accepted, even if the ranked view projection needs to catch up afterward.

• What's the trade-off of synchronous log-commit vs. a faster, less durable ack? — Synchronous commit-before-ack maximizes the durability guarantee at a small latency cost per submission; acking before durable commit is faster but risks a committed-to-the-client event that the system can't actually reproduce after a crash — rarely an acceptable trade for score integrity.

Be precise about what 'crash after commit' means: the data is durably committed — the ranked view already reflects the score, and the event log already has the event — even though whatever was waiting to be told 'processing complete' never received that confirmation. Recovery must redeliver the already-true outcome (confirm the event was in fact applied, by checking the idempotency record) rather than re-executing the projection step, which would risk a duplicate application if the idempotency check itself weren't trusted.

• Why is this fundamentally different from a lost event? — A lost event (never committed to the log at all) is genuinely absent from the system of record and needs to be resubmitted; a lost acknowledgment (committed, but confirmation never arrived) is already present and correct, and querying current state will show the true, already-applied outcome — conflating the two leads to incorrect, duplicate-prone retry logic.

Not transparently — a live comparator change mid-season silently redefines what every existing ranked position means, which is effectively a correctness break for anyone who already has a rank under the old rule. The safe path is to treat a comparator change as a new leaderboard (or a new season) rather than mutating the live ranking rule of an in-progress board, and to communicate it as a deliberate, versioned change.

• What if the business genuinely needs this mid-season for a live event? — Then it should be modeled as a distinct, newly-created leaderboard scope running in parallel, not a redefinition of the existing one — preserving the old board's historical meaning intact.

A correction event must be explicit, auditable, and applied through the same idempotent event-application path as any other event — referencing exactly which prior event it corrects or invalidates, rather than an ad hoc direct mutation of a player's stored score. Test G is this exact scenario: Ava's score is invalidated, and the resulting re-rank (Ben #1, Chloe #2, Dev #3, Eli #4) is a direct, traceable consequence of that one correction event, not a hand-edited board.

• Does this requirement extend to cumulative-mode corrections? — Yes, and it's trickier there — reversing a prior cumulative addition means emitting a compensating negative adjustment event (also idempotent on its own event ID), not simply recomputing the sum from a hand-edited history.

A season's final standings (and anything gated on them, like payouts or rewards) should only be finalized after an explicit grace/moderation window during which late corrections can still be applied — finalizing and paying out immediately at season-close, then trying to claw back a payout after a correction surfaces, is a far worse failure mode than a brief, clearly communicated delay before finalization.

• What's a concrete failure if this grace window is skipped? — A cheater's inflated score could gate a legitimate reward decision (prize money, exclusive items) before moderation has a chance to invalidate it — the cost of being wrong here is much higher than the cost of a short, deliberate delay.

Allowing every region to accept and apply score events locally and independently risks the same player's score being updated inconsistently across regions before replication catches up — the safer default is a single authoritative write path (or region) for a given global board, with other regions as fast read replicas, accepting the latency cost of cross-region writes as an explicit trade-off rather than claiming multi-region active-active correctness for free.

• Does this conflict with wanting low write latency for players in every region? — Yes, directly — this is the real trade-off to name: either accept higher write latency for non-authoritative regions, or accept the complexity (and correctness risk) of genuine multi-region write reconciliation, which is a materially harder problem than this design defaults to solving.

A friends-only ranking must only ever be computed from a friend list the requesting player is actually entitled to see, and it must not leak a non-friend's score or existence through the ranking response — the leaderboard service should treat the social-graph service's friend list as the sole source of eligibility, and never attempt its own inference (e.g. 'players who share a region') as a substitute.

• Could a rank-around-player query accidentally leak a non-friend's score? — Only if rank-around-player and friends-only are implemented as the same code path without an explicit eligibility filter — they must be kept conceptually distinct: one windows the global board, the other filters to an explicit friend-ID set.

Yes, as long as every event application is genuinely idempotent on its unique event ID and every comparator respects the stated mode's rule (conditional max for highest-score, additive-once for cumulative) — reprocessing the entire historical log from scratch should always converge to the identical final ranked state as the original incremental processing did, which is exactly what Test C demonstrates at a single-event scale.

• What would make reprocessing unsafe? — Any non-idempotent side effect tied to event application — e.g. sending a 'new high score!' notification as a direct side effect of the same code path that updates rank — reprocessing would then re-trigger notifications that already happened, which is why side effects like that should be decoupled from the core ranking state transition.

Memory cost scales with the number of ranked members, not with read volume — so the real planning question is player count per board (and how many distinct board scopes exist: per-season, per-mode, per-region), not request rate. A design should name this as the actual capacity driver and state an illustrative assumption for it explicitly, rather than treating Redis memory as unlimited or ignoring it entirely.

• Does season rollover help bound this? — Yes — since each season's board is a bounded, eventually-archivable structure rather than an ever-growing single board, season rollover is also a practical memory-management mechanism, not just a product/ranking reset.

The achievement timestamp used for tie-breaking should come from a trusted, consistent source (the game server or event pipeline's clock), not from an untrusted client clock — if timestamps aren't reasonably synchronized across the servers producing them, two legitimately near-simultaneous achievements could be tie-broken in a way that doesn't reflect true order. This needs an explicit, stated assumption about timestamp trustworthiness and synchronization, not a silent assumption that all timestamps are perfectly comparable.

• Could you use a logical/sequence counter instead of wall-clock time for the tiebreaker? — That's a legitimate alternative worth naming — a server-assigned monotonic sequence number avoids clock-skew risk entirely, at the cost of the tiebreaker no longer directly reflecting real-world achievement time; which one FlowRank uses should be a stated, deliberate choice.

Name the actual hot-path stages (client, cache/read-replica, sorted-set lookup) and reason about where queueing delay grows nonlinearly as utilization approaches capacity — a credible answer identifies that uncached rank-around-player and friends-subset queries (which require a lookup plus a multi-get) are more expensive than a cached top-N read, and that headroom on the hottest shard, not just average throughput, is what protects tail latency.

• What's a concrete lever specifically for the friends-only path? — Bounding and batching the per-friend multi-get (rather than issuing one round trip per friend) keeps that path's own tail latency from dominating an otherwise fast global-board read path.

Pushing every rank-affecting mutation to every potentially-interested connected client doesn't scale linearly forever — the fan-out cost should be bounded by only notifying clients actually watching a board region that changed (their own rank, or the specific top-N page they have open), and by batching/coalescing rapid successive updates rather than pushing every single intermediate mutation individually.

• Is there a risk of over-coalescing and feeling less 'real-time'? — Yes — this is the same bounded-staleness trade-off from the core section, just applied to push timing specifically; a small, stated coalescing window (e.g. batch updates every few hundred milliseconds) is a deliberate trade-off, not an accidental degradation.

Every rank a player ever held should be reconstructable from the immutable event log plus the deterministic comparator and tie-break rules — not just observable as 'whatever the live sorted set currently shows.' This means the event log, not the live ranked view, is the actual audit source of truth, the same pattern used for correction events (Test G) and reprocessing (Test C).

• Why can't the live sorted set alone serve as the audit trail? — It only reflects current state — a player who was later corrected out of a rank, or whose season closed and rolled over, no longer has their historical position visible in the live structure at all; only the event log preserves that history.

Run both systems in parallel: build the new event log and sorted-set projection from the existing relational data as a one-time backfill, verify the resulting ranked view exactly matches the old system's output for a representative sample (including every tie-break case), then cut reads over to the new system only after that verification passes — never a hard cutover based on 'it looks right' alone.

• What's the single highest-risk verification case to get right? — The tie-break cases specifically (Test B-style scenarios) — a migration that gets simple distinct-score ranks right but subtly reorders tied players is exactly the kind of regression that's easy to miss in a casual spot-check and obvious the moment a real tie occurs in production.

A leaderboard is a sorted list with a specific, product-defined comparator (not just numeric ordering), a stable tie-break rule, and a requirement to answer rank-position queries efficiently (top-N, a specific player's rank, a window around a player) — not merely to render a sorted page once.

• Does that mean a leaderboard always needs a specialized data structure? — Not at small scale — a simple sorted query can suffice; the specialized structure becomes necessary once read volume or rank-query latency requirements exceed what a plain sorted scan can deliver.

A per-match scoreboard is scoped to one short-lived match and typically discarded or archived after it ends; a persistent global leaderboard (like FlowRank's season S7 global board) aggregates across many matches/sessions over an extended period and must handle season rollover, corrections, and long-term storage concerns a per-match scoreboard never faces.

• Can the same underlying event stream feed both? — Yes — a single verified-score event can simultaneously update a per-match scoreboard and contribute to the persistent global leaderboard; they're two different projections of the same source events, not two separate systems collecting data independently.

Because every one of those dimensions (game, mode, season, scope) defines a logically separate ranked structure with its own player set and its own comparator state — collapsing them into one undifferentiated 'the leaderboard' would silently mix unrelated rankings together, which is a correctness bug, not just an organizational nicety.

• How many of these dimensions does a real product typically need simultaneously? — Often several at once (e.g. multiple modes, a rolling season, a global and a regional board) — the architecture should treat scope as a first-class key on every stored score and every query, not an implicit global assumption.

O(log N) for a balanced-structure-backed sorted set (N = number of ranked members) to both locate the correct position and update it — independent of where in the ranking the new score lands, which is exactly why this beats a full re-sort on every write.

• Does a batch of simultaneous score updates change this complexity? — Each individual update is still O(log N); a batch of K updates is O(K log N) if applied one at a time, though some implementations can offer batched-insert optimizations worth naming if asked.

Because a single score change anywhere in the board can shift every other player's rank below it by one position — precomputing and storing rank as a static field would require updating potentially many other rows on every write, which is far more expensive than deriving rank on read from an already-ordered structure.

• Is there any case where caching a computed rank is still worthwhile? — Yes — for a short-TTL cached response to a specific, repeated rank query (e.g. a popular player's own rank), as long as it's clearly a cache of a point-in-time answer, not a source-of-truth field that must always be correct.

Store the raw completion time as the sort key directly, since the structure's native ascending order already matches 'lower time ranks higher' — the opposite of highest-score mode, which needs its sort key's natural direction inverted or its ordering queried in reverse to express 'higher score ranks higher.'

• Could using the same stored-value convention for both modes cause a bug? — Yes — a projector or query layer that doesn't explicitly branch its comparison/ordering logic per mode could apply highest-score-mode's descending convention to a fastest-time board by mistake, inverting the entire ranking silently.

Every ranked player has a distinct, gap-free integer rank (1, 2, 3, ...) with no two players sharing a rank and no rank skipped — the comparator and tie-break rule together must produce a strict total order at all times, which is the invariant every mode (highest-score, cumulative, fastest-time) must independently satisfy.

• How would you test this invariant automatically? — A property-based test that applies a random sequence of valid events (including same-score, same-timestamp edge cases) and asserts the resulting rank sequence is always a strict, gap-free permutation with no duplicate ranks.

For highest-score and cumulative modes with proper idempotent, order-independent application rules (conditional max; additive-once-per-ID), the final state converges identically regardless of application order — this is a deliberately designed property, not an accident, and it's exactly what makes safe reprocessing (Test C) and recovery possible.

• Does this property hold for a hypothetical mode where only the *most recent* score counts, regardless of value? — No — a 'most recent wins' comparator is explicitly order-dependent, so applying events out of true timestamp order would produce a different, wrong final state; this is a deliberate counter-example worth naming to show the convergence property isn't automatic for every possible mode.

Strict global ordering across all players isn't required — each mode's correctness only depends on per-player ordering being eventually resolved correctly via the comparator (conditional max, additive, etc.), not on a single global sequence number across the entire event stream; this is a deliberately weaker, more scalable requirement than, say, a matching engine's strict per-book ordering.

• Does this mean partitioning the event stream by player ID is safe? — Yes — since correctness is per-player, partitioning the event pipeline by player ID (so one player's events are processed in a consistent relative order) is a safe and natural scaling approach.

Track the gap between the latest committed event sequence/version in the log and the last version the projector has successfully applied and published — an explicit, monitored lag metric, not an assumption that the projector is always caught up.

• What should happen automatically once lag exceeds a threshold? — Alerting at minimum, and potentially a read-path signal (e.g. serving slightly-stale-flagged responses) so clients and the season-close procedure can both react to a known degraded state rather than silently trusting a lagging view.

They should read from the same underlying ranked-view projection (so pushed updates and subsequently-queried state are always consistent with each other), but the delivery mechanisms are different — one is a fan-out notification system, the other is a request/response query — and conflating the two into one code path risks coupling push-delivery failures to read-path availability.

• What's a concrete symptom of getting this coupling wrong? — A slow or overloaded push-fan-out layer causing ordinary top-N or rank queries to also slow down or fail, when the two should be able to degrade independently.

As a direct extension of the already-stated bounded-staleness contract — the coalescing window should be a known, small fraction of (or equal to) that staleness bound, so batching updates doesn't silently introduce a separate, unaccounted-for delay on top of the one already promised.

• Should the coalescing window be the same for a top-N feed and a single player's own-rank feed? — Not necessarily — a player's own rank crossing a meaningful boundary (e.g. entering the top 10) might justify a tighter, more immediate push than a less time-sensitive general top-100 display, which is a legitimate product-level distinction to raise.

Memory footprint and single-node throughput of the ranked-view structure, not the event log itself (which is naturally append-only and horizontally scalable) — this is why partitioning strategy for the ranked view (not the event pipeline) is the central scaling decision at very large player counts.

• Does sharding the ranked view also help write throughput, or only read/memory? — Both, to a point — write throughput for a given shard is still bounded by that shard's own capacity, so sharding spreads write load across shards the same way it spreads read/memory load, as long as writes are reasonably distributed across player IDs rather than concentrated.

Each region maintains its own authoritative local ranked view for low-latency regional reads, while a separate aggregation process periodically (or continuously, with accepted lag) merges regional data into a global view — this is a deliberate, bounded-staleness roll-up, not a claim that the global view is always instantaneously consistent with every region.

• What happens to a player who transfers regions mid-season? — Their historical regional scores need an explicit, stated policy — carried forward into the new region's local view, kept separately, or excluded — rather than an implicit assumption about what 'moving region' means for ranking.

Server-side, authoritatively — the server is the only party that can be trusted to reject a late S7 event or correctly route a fresh event to S8; a client-side season check is, at best, a UX nicety and must never be relied on for correctness.

• What's a concrete exploit if this were trusted client-side? — A manipulated or outdated client could submit an S7-scoped event after the season has closed and claim it should still count — the server's authoritative season-state check is what actually prevents this, not client cooperation.

By never accepting a raw client-submitted score as ranking-eligible at all — only scores that have passed through the trusted, server-side verified game-server/anti-cheat pipeline (carrying its own event ID and achievement timestamp) are eligible to affect rank, which structurally removes the client's ability to just assert an arbitrary number.

• Does this fully eliminate cheating risk? — No — it shifts the trust boundary to the verification pipeline itself, which needs its own integrity guarantees; the leaderboard's job is to correctly apply whatever that pipeline hands it, not to be the last line of defense against cheating.

Yes — this is a correctness-and-auditability-driven choice, not a cost-driven one; unlimited budget buys more shards, more replicas, and lower projection lag, but it doesn't remove the need for an authoritative, replayable record that corrections, audits, and recovery all depend on. A strong answer separates 'what more money buys' from 'what the correctness/auditability requirement demands.'

• What would unlimited budget actually change, then? — Lower projection lag (more projector capacity), more aggressive caching and regional replication, and more generous exact-rank guarantees at larger shard counts — all performance/availability levers, not a different correctness model.

Watch for the single-node structure's memory footprint or write/read throughput approaching its practical ceiling under real, measured traffic — not a guessed player-count threshold decided in advance — and treat the migration itself as requiring the same zero-regression verification discipline described in the staff-level migration question in Section 4.

• What's the actual signal that would trigger this change? — Sustained elevated p99 latency on rank queries or memory pressure alerts on the node holding the ranked view, even when no single player or key is behaving unusually — that's the tell that the bottleneck is the single structure itself, not a hot key.