System Design Deep Dive ·

🎯 Design Leaderboard

1️⃣ Core Framework

When discussing Leaderboard design, I frame it as:

Score update model
Ranking query model
Global vs regional vs friend leaderboard
Real-time vs batch leaderboard
Storage and indexing strategy
Time-window leaderboard
Anti-cheat and validation
Trade-offs: latency vs accuracy vs scalability

2️⃣ Core Requirements

Functional Requirements

Users can submit scores
Users can view top N rankings
Users can view their own rank
Support global leaderboard
Support regional leaderboard
Support friend leaderboard
Support daily / weekly / monthly leaderboard
Support score history
Support anti-cheat validation

Non-functional Requirements

Low-latency score updates
Low-latency rank reads
High write throughput
High read throughput
Scalable ranking queries
High availability
Eventually consistent rankings may be acceptable
Stronger correctness needed for final rewards

👉 Interview Answer

A leaderboard system stores user scores and returns ranked results efficiently.

The main challenge is supporting high-volume score updates and fast rank queries, especially for global and time-window leaderboards.

3️⃣ Main APIs

Submit Score

POST /api/leaderboard/scores

Request:

{
  "userId": "u123",
  "score": 9850,
  "gameMode": "ranked",
  "region": "NA"
}

Get Top Rankings

GET /api/leaderboard?gameMode=ranked&period=weekly&limit=100

Get User Rank

GET /api/leaderboard/rank?userId=u123&gameMode=ranked&period=weekly

Get Nearby Rankings

GET /api/leaderboard/nearby?userId=u123&window=10

👉 Interview Answer

I would expose APIs for submitting scores, getting top rankings, getting a user’s rank, and getting rankings around a user.

Top-N and nearby-rank queries are the most important read patterns.

4️⃣ Data Model

Score Table

user_score (
  user_id VARCHAR,
  leaderboard_id VARCHAR,
  score BIGINT,
  updated_at TIMESTAMP,
  PRIMARY KEY (leaderboard_id, user_id)
)

Score Event Table

score_event (
  event_id VARCHAR PRIMARY KEY,
  user_id VARCHAR,
  leaderboard_id VARCHAR,
  score BIGINT,
  event_type VARCHAR,
  created_at TIMESTAMP,
  metadata JSON
)

Leaderboard Config Table

leaderboard_config (
  leaderboard_id VARCHAR PRIMARY KEY,
  game_mode VARCHAR,
  region VARCHAR,
  period VARCHAR,
  start_time TIMESTAMP,
  end_time TIMESTAMP,
  ranking_rule VARCHAR
)

Reward Table

leaderboard_reward (
  reward_id VARCHAR PRIMARY KEY,
  leaderboard_id VARCHAR,
  user_id VARCHAR,
  rank INT,
  reward_status VARCHAR,
  created_at TIMESTAMP
)

👉 Interview Answer

I would separate current score, score events, leaderboard configuration, and rewards.

Current score supports fast ranking, while score events provide audit history and allow rebuilding leaderboards if needed.

5️⃣ Score Update Flow

Basic Flow

User finishes game
→ Game service validates score
→ Score event created
→ Leaderboard service updates ranking index
→ User rank changes
→ Event emitted for analytics/rewards

Score Update Rules

Common rules:

highest score wins
latest score wins
total accumulated score wins
fastest completion time wins

Example: Highest Score Wins

current score = 9000
new score = 9850
update score to 9850

If:

new score = 8500
ignore update

👉 Interview Answer

Score update depends on the ranking rule.

For many games, only the highest score should be stored.

The system should validate the score, write a score event, and update the leaderboard index only if the new score changes the ranking.

6️⃣ Ranking Storage

Option 1: SQL Database

Use:

ORDER BY score DESC LIMIT 100

Pros

Simple
Strong consistency possible

Cons

Expensive at scale
Slow for high write and rank queries
Hard to get user rank efficiently

Option 2: Redis Sorted Set

Use:

ZADD leaderboard score user_id
ZREVRANGE leaderboard 0 99 WITHSCORES
ZREVRANK leaderboard user_id

Pros

Very fast rank queries
Simple top-N support
Great for real-time leaderboard

Cons

Memory cost
Need persistence / backup
Large global leaderboard may need sharding

Option 3: Batch / OLAP Leaderboard

Compute periodically.

Pros

Scales well for huge data
Good for daily/weekly final rankings

Cons

Not real-time

👉 Interview Answer

For real-time leaderboards, I would use Redis Sorted Sets because they support efficient score updates, top-N queries, and user rank queries.

For final historical rankings or analytics, I would also persist events and compute batch results offline.

7️⃣ Redis Sorted Set Design

Key Design

leaderboard:{game_mode}:{region}:{period}

Example:

leaderboard:ranked:NA:weekly:2026-W20

Operations

Update Score

ZADD leaderboard 9850 u123

Get Top 100

ZREVRANGE leaderboard 0 99 WITHSCORES

Get User Rank

ZREVRANK leaderboard u123

Get Nearby Users

rank = ZREVRANK leaderboard u123
ZREVRANGE leaderboard rank-5 rank+5 WITHSCORES

👉 Interview Answer

Redis Sorted Set is a natural fit.

It stores users ordered by score, supports top-N ranking, user rank lookup, and nearby rank queries efficiently.

The key should include game mode, region, and time period so different leaderboards are isolated.

8️⃣ Time-window Leaderboards

Common Periods

Daily
Weekly
Monthly
Season
Event-based

Key Strategy

leaderboard:daily:2026-05-03
leaderboard:weekly:2026-W20
leaderboard:season:S12

Expiration

Old leaderboards can be:

Archived
Moved to cold storage
Kept for reward history
Deleted after retention period

👉 Interview Answer

I would create separate leaderboard keys for each time window.

For example, daily and weekly leaderboards should be different sorted sets.

At the end of a period, the leaderboard is finalized, rewards are calculated, and the data can be archived.

9️⃣ Global vs Regional vs Friend Leaderboards

Global Leaderboard

All users.

Challenge:

Very large scale
High write volume
Hot key risk

Regional Leaderboard

Partition by region.

leaderboard:ranked:NA
leaderboard:ranked:EU
leaderboard:ranked:APAC

Pros:

Smaller leaderboards
Lower latency
Better user relevance

Friend Leaderboard

Query ranks among user’s friends.

Options:

Fetch friends and scores, sort in app/service
Precompute friend leaderboard for active users
Use social graph + score lookup

👉 Interview Answer

Global leaderboards are harder because they can become very large and hot.

Regional leaderboards are easier to scale and often more meaningful to users.

Friend leaderboards are usually computed by fetching a user’s friends, looking up their scores, and sorting that smaller set.

🔟 Sharding Large Leaderboards

Problem

One huge sorted set may not fit on one node.

Strategy 1: Shard by User ID

shard = hash(user_id) % N

Each shard stores partial leaderboard.

To get global top N:

query top N from each shard
→ merge globally

Strategy 2: Shard by Score Range

score 9000-10000 → shard A
score 8000-8999 → shard B

Pros:

Easier top ranking

Cons:

Hot high-score shard
Score range rebalancing complexity

Strategy 3: Regional Partitioning

Shard naturally by region or game mode.

👉 Interview Answer

For very large leaderboards, I would shard by region or user ID.

If sharded by user ID, each shard can return its local top results, and a coordinator merges them into global top N.

This keeps writes distributed, but global rank calculation becomes more complex.

1️⃣1️⃣ Rank Query Challenges

Top N Query

Easy with sorted set.

ZREVRANGE 0 N

User Rank Query

Easy in single sorted set.

ZREVRANK user_id

Global Rank in Sharded System

Harder.

Need:

count users with score > user_score across all shards

Possible approaches:

Query all shards
Maintain score histograms
Approximate rank
Use batch-computed ranks

👉 Interview Answer

User rank is simple in a single sorted set, but more complex in a sharded leaderboard.

For exact global rank, we may need to count how many users have higher scores across shards.

If exact real-time rank is too expensive, we can provide approximate rank online and compute exact final ranks offline.

1️⃣2️⃣ Anti-cheat and Score Validation

Why Needed?

Leaderboard rewards create incentives to cheat.

Validation Signals

Impossible score
Impossible completion time
Client tampering
Repeated suspicious submissions
Device fingerprint
Server-side game logs
Replay validation

Strategy

Never fully trust client score
Validate score server-side when possible
Use fraud scoring
Quarantine suspicious scores
Manual review for top ranks
Delay reward distribution until validation

👉 Interview Answer

Leaderboard scores should not be blindly trusted.

The system should validate scores using server-side events, game rules, completion time, fraud signals, and anomaly detection.

Suspicious scores can be quarantined and excluded from final rewards until reviewed.

1️⃣3️⃣ Rewards and Finalization

Reward Flow

Leaderboard period ends
→ Freeze leaderboard
→ Validate top scores
→ Calculate final ranks
→ Create reward records
→ Distribute rewards
→ Archive final result

Important Rules

Final ranks should be strongly controlled
Rewards should be idempotent
Suspicious users may be excluded
Keep audit trail

👉 Interview Answer

For reward distribution, I would not rely only on real-time leaderboard state.

At period end, the system should freeze the leaderboard, validate top scores, compute final ranks, and distribute rewards idempotently.

1️⃣4️⃣ Caching and Read Optimization

What to Cache?

Top 100 leaderboard
User rank
Nearby rank results
User profile display data
Friend leaderboard

Read Optimization

Cache top-N aggressively
Denormalize username/avatar for display
Batch fetch user profiles
Use CDN for public leaderboard pages
Use short TTL for rank caches

👉 Interview Answer

Leaderboards are read-heavy.

I would cache top-N results, nearby rank results, and user display metadata.

But score updates should still go to the authoritative ranking store.

1️⃣5️⃣ Scaling Patterns

Pattern 1: Real-time Store + Durable Event Log

Redis Sorted Set for serving
Score events for audit/rebuild

Pattern 2: Separate Read and Write Paths

Score update path
Ranking query path

Pattern 3: Time-window Partitioning

Separate sorted sets per day/week/season.

Pattern 4: Regional Partitioning

Reduce global hot spots.

Pattern 5: Batch Finalization

Use offline jobs for exact final ranks and rewards.

👉 Interview Answer

To scale leaderboards, I would use Redis Sorted Sets for real-time ranking, persist score events for durability, partition by time window and region, and use batch jobs for final ranking and rewards.

1️⃣6️⃣ Failure Handling

Common Failures

Score update timeout
Duplicate score submission
Redis unavailable
Event log write failure
Rank query timeout
Suspicious score submitted
Reward job partially fails

Strategies

Idempotency keys
Durable score event log
Retry score updates
Rebuild Redis from events
Fallback to cached top-N
Quarantine suspicious scores
Idempotent reward distribution

👉 Interview Answer

The system should persist score events durably, so the leaderboard can be rebuilt if Redis fails.

Score submission should be idempotent, and reward distribution must also be idempotent.

For read failures, the system can fall back to cached top-N results.

1️⃣7️⃣ Consistency Model

Stronger Consistency Needed For

Score event persistence
Final rank calculation
Reward distribution
Anti-cheat decisions
Idempotency records

Eventual Consistency Acceptable For

Real-time displayed rank
Friend leaderboard
Regional display
User profile metadata
Analytics

👉 Interview Answer

Real-time leaderboard display can often be eventually consistent.

A user seeing their rank update a few seconds late is acceptable.

But final ranks and reward distribution require stronger correctness.

1️⃣8️⃣ Observability

Key Metrics

Score submission QPS
Score update latency
Ranking query latency
Redis memory usage
Sorted set size
Top-N cache hit rate
Duplicate submission count
Suspicious score count
Reward job failure rate
Leaderboard rebuild time

👉 Interview Answer

I would monitor score submission rate, rank query latency, Redis memory usage, sorted set size, cache hit rate, suspicious score count, reward job failures, and rebuild time.

These metrics show both system health and competition integrity.

1️⃣9️⃣ End-to-End Flow

Score Update Flow

User completes game
→ Game service validates score
→ Score event persisted
→ Leaderboard sorted set updated
→ Rank updated
→ Analytics event emitted

Ranking Read Flow

User opens leaderboard
→ Read top N from cache or Redis
→ Fetch user profile metadata
→ Return ranked list

Finalization Flow

Leaderboard period ends
→ Freeze leaderboard
→ Validate top scores
→ Compute final ranks
→ Create reward records
→ Distribute rewards
→ Archive leaderboard

Key Insight

Leaderboard System is not just sorting users — it is a real-time ranking system with durability and fairness requirements.

🧠 Staff-Level Answer (Final)

👉 Interview Answer (Full Version)

When designing a leaderboard system, I think of it as a real-time ranking system.

The system must support high-volume score submissions, fast top-N queries, user rank lookup, nearby rank queries, and time-window rankings such as daily, weekly, or seasonal leaderboards.

For real-time ranking, I would use Redis Sorted Sets, because they support efficient score updates, top-N queries, and rank lookup.

I would also persist every score submission as an immutable score event, so the leaderboard can be audited and rebuilt if needed.

Leaderboard keys should include dimensions such as game mode, region, and time period.

For very large leaderboards, I would partition by region, game mode, or user ID.

If exact global rank becomes too expensive, the system can return approximate real-time rank and compute exact final ranks offline.

Score validation is important because rewards create incentives to cheat. I would validate scores server-side when possible, detect suspicious submissions, quarantine abnormal scores, and review top ranks before reward distribution.

Real-time displayed rank can be eventually consistent, but final rank calculation and rewards require stronger correctness.

The main trade-offs are latency, accuracy, memory cost, rank query complexity, and anti-cheat enforcement.

Ultimately, the goal is to provide fast and engaging ranking updates while preserving durable score history, fair competition, and correct final results.

⭐ Final Insight

Leaderboard 的核心不是简单排序，而是一个支持实时排名、时间窗口、反作弊、最终结算和奖励发放的排名系统。

中文部分

🎯 Design Leaderboard

1️⃣ 核心框架

在设计 Leaderboard 时，我通常从以下几个方面分析：

Score update model
Ranking query model
Global / regional / friend leaderboard
Real-time vs batch leaderboard
Storage and indexing strategy
Time-window leaderboard
Anti-cheat and validation
核心权衡：latency vs accuracy vs scalability

2️⃣ 核心需求

功能需求

用户可以提交分数
用户可以查看 top N rankings
用户可以查看自己的 rank
支持 global leaderboard
支持 regional leaderboard
支持 friend leaderboard
支持 daily / weekly / monthly leaderboard
支持 score history
支持 anti-cheat validation

非功能需求

Score update 低延迟
Rank reads 低延迟
高写入吞吐
高读取吞吐
可扩展 ranking queries
高可用
实时排名可以最终一致
Final rewards 需要更强正确性

👉 面试回答

Leaderboard System 存储用户分数，并高效返回排名结果。

核心挑战是支持大量 score updates 和快速 rank queries，尤其是 global leaderboard 和 time-window leaderboards。

3️⃣ 主要 API

Submit Score

POST /api/leaderboard/scores

Request:

{
  "userId": "u123",
  "score": 9850,
  "gameMode": "ranked",
  "region": "NA"
}

Get Top Rankings

GET /api/leaderboard?gameMode=ranked&period=weekly&limit=100

Get User Rank

GET /api/leaderboard/rank?userId=u123&gameMode=ranked&period=weekly

Get Nearby Rankings

GET /api/leaderboard/nearby?userId=u123&window=10

👉 面试回答

我会提供 submit score、get top rankings、 get user rank 和 get nearby rankings 的 API。

Top-N 和 nearby-rank queries 是最重要的读模式。

4️⃣ 数据模型

Score Table

user_score (
  user_id VARCHAR,
  leaderboard_id VARCHAR,
  score BIGINT,
  updated_at TIMESTAMP,
  PRIMARY KEY (leaderboard_id, user_id)
)

Score Event Table

score_event (
  event_id VARCHAR PRIMARY KEY,
  user_id VARCHAR,
  leaderboard_id VARCHAR,
  score BIGINT,
  event_type VARCHAR,
  created_at TIMESTAMP,
  metadata JSON
)

Leaderboard Config Table

leaderboard_config (
  leaderboard_id VARCHAR PRIMARY KEY,
  game_mode VARCHAR,
  region VARCHAR,
  period VARCHAR,
  start_time TIMESTAMP,
  end_time TIMESTAMP,
  ranking_rule VARCHAR
)

Reward Table

leaderboard_reward (
  reward_id VARCHAR PRIMARY KEY,
  leaderboard_id VARCHAR,
  user_id VARCHAR,
  rank INT,
  reward_status VARCHAR,
  created_at TIMESTAMP
)

👉 面试回答

我会将 current score、score events、 leaderboard configuration 和 rewards 分开。

Current score 支持快速排名； score events 提供 audit history，并允许系统在需要时重建 leaderboard。

5️⃣ Score Update Flow

Basic Flow

User finishes game
→ Game service validates score
→ Score event created
→ Leaderboard service updates ranking index
→ User rank changes
→ Event emitted for analytics/rewards

Score Update Rules

常见规则：

highest score wins
latest score wins
total accumulated score wins
fastest completion time wins

Example: Highest Score Wins

current score = 9000
new score = 9850
update score to 9850

如果：

new score = 8500
ignore update

👉 面试回答

Score update 取决于 ranking rule。

对很多游戏来说，只需要保存最高分。

系统应该先验证分数，写入 score event，并且只有当新分数会改变排名时才更新 leaderboard index。

6️⃣ Ranking Storage

Option 1: SQL Database

使用：

ORDER BY score DESC LIMIT 100

优点

简单
可以提供强一致

缺点

大规模下昂贵
高写入和 rank queries 较慢
难以高效获取用户 rank

Option 2: Redis Sorted Set

使用：

ZADD leaderboard score user_id
ZREVRANGE leaderboard 0 99 WITHSCORES
ZREVRANK leaderboard user_id

优点

Rank queries 非常快
简单支持 top-N
非常适合 real-time leaderboard

缺点

内存成本
需要 persistence / backup
大型 global leaderboard 可能需要 sharding

Option 3: Batch / OLAP Leaderboard

周期性计算。

优点

对超大数据规模友好
适合 daily / weekly final rankings

缺点

不实时

👉 面试回答

对 real-time leaderboard，我会使用 Redis Sorted Sets，因为它支持高效 score updates、 top-N queries 和 user rank queries。

对 final historical rankings 或 analytics，我也会持久化 events，并离线计算 batch results。

7️⃣ Redis Sorted Set Design

Key Design

leaderboard:{game_mode}:{region}:{period}

示例：

leaderboard:ranked:NA:weekly:2026-W20

Operations

Update Score

ZADD leaderboard 9850 u123

Get Top 100

ZREVRANGE leaderboard 0 99 WITHSCORES

Get User Rank

ZREVRANK leaderboard u123

Get Nearby Users

rank = ZREVRANK leaderboard u123
ZREVRANGE leaderboard rank-5 rank+5 WITHSCORES

👉 面试回答

Redis Sorted Set 非常适合 leaderboard。

它会按照 score 排序 users，支持 top-N ranking、user rank lookup 和 nearby rank queries。

Key 应该包含 game mode、region 和 time period，这样不同 leaderboards 可以互相隔离。

8️⃣ Time-window Leaderboards

Common Periods

Daily
Weekly
Monthly
Season
Event-based

Key Strategy

leaderboard:daily:2026-05-03
leaderboard:weekly:2026-W20
leaderboard:season:S12

Expiration

旧 leaderboards 可以：

Archived
Moved to cold storage
Kept for reward history
Deleted after retention period

👉 面试回答

我会为每个 time window 创建独立 leaderboard key。

例如 daily 和 weekly leaderboards 应该是不同的 sorted sets。

在 period 结束时， leaderboard 会被 finalized， rewards 会被计算，数据可以归档。

9️⃣ Global vs Regional vs Friend Leaderboards

Global Leaderboard

所有用户。

挑战：

数据规模非常大
写入量高
Hot key risk

Regional Leaderboard

按 region 分区。

leaderboard:ranked:NA
leaderboard:ranked:EU
leaderboard:ranked:APAC

优点：

Leaderboard 更小
延迟更低
对用户更有意义

Friend Leaderboard

查询朋友之间的排名。

Options:

获取 friends 和 scores，在 app / service 中排序
对活跃用户预计算 friend leaderboard
使用 social graph + score lookup

👉 面试回答

Global leaderboard 更难，因为它可能非常大并且容易变成 hot key。

Regional leaderboard 更容易扩展，而且通常对用户更有意义。

Friend leaderboard 通常可以通过获取用户朋友列表、查询他们的 scores，然后对这个较小集合排序来实现。

🔟 Sharding Large Leaderboards

Problem

一个巨大 sorted set 可能无法放在单个节点上。

Strategy 1: Shard by User ID

shard = hash(user_id) % N

每个 shard 存储一部分 leaderboard。

获取 global top N：

query top N from each shard
→ merge globally

Strategy 2: Shard by Score Range

score 9000-10000 → shard A
score 8000-8999 → shard B

优点：

Top ranking 更容易

缺点：

高分 shard 容易成为热点
Score range rebalancing 复杂

Strategy 3: Regional Partitioning

按 region 或 game mode 自然分区。

👉 面试回答

对非常大的 leaderboards，我会按 region 或 user ID 分片。

如果按 user ID 分片，每个 shard 返回本地 top results， coordinator 再合并成 global top N。

这样可以分散写入，但 global rank calculation 会更复杂。

1️⃣1️⃣ Rank Query Challenges

Top N Query

Sorted set 中很容易：

ZREVRANGE 0 N

User Rank Query

单个 sorted set 中也很容易：

ZREVRANK user_id

Global Rank in Sharded System

更难。

需要：

count users with score > user_score across all shards

可选方案：

Query all shards
Maintain score histograms
Approximate rank
Use batch-computed ranks

👉 面试回答

User rank 在单个 sorted set 中很简单，但在 sharded leaderboard 中更复杂。

对 exact global rank，我们可能需要统计所有 shards 中有多少用户分数高于当前用户。

如果 exact real-time rank 成本太高，可以在线返回 approximate rank，并离线计算最终 exact rank。

1️⃣2️⃣ Anti-cheat and Score Validation

为什么需要？

Leaderboard rewards 会激励作弊。

Validation Signals

Impossible score
Impossible completion time
Client tampering
Repeated suspicious submissions
Device fingerprint
Server-side game logs
Replay validation

Strategy

永远不要完全信任 client score
尽可能 server-side validate score
使用 fraud scoring
Quarantine suspicious scores
Top ranks manual review
Reward distribution 前延迟验证

👉 面试回答

Leaderboard scores 不能盲目信任。

系统应该使用 server-side events、game rules、 completion time、fraud signals 和 anomaly detection 来验证分数。

Suspicious scores 可以被 quarantine，在 review 之前不进入 final rewards。

1️⃣3️⃣ Rewards and Finalization

Reward Flow

Leaderboard period ends
→ Freeze leaderboard
→ Validate top scores
→ Calculate final ranks
→ Create reward records
→ Distribute rewards
→ Archive final result

Important Rules

Final ranks 需要强控制
Rewards 必须幂等
Suspicious users 可以被排除
保留 audit trail

👉 面试回答

对 reward distribution，我不会只依赖 real-time leaderboard state。

Period 结束时，系统应该 freeze leaderboard，验证 top scores，计算 final ranks，并幂等发放 rewards。

1️⃣4️⃣ Caching and Read Optimization

What to Cache?

Top 100 leaderboard
User rank
Nearby rank results
User profile display data
Friend leaderboard

Read Optimization

Cache top-N aggressively
Denormalize username/avatar for display
Batch fetch user profiles
Public leaderboard pages 可以用 CDN
Rank caches 使用短 TTL

👉 面试回答

Leaderboards 是 read-heavy。

我会缓存 top-N results、nearby rank results 和 user display metadata。

但 score updates 仍然应该写入 authoritative ranking store。

1️⃣5️⃣ Scaling Patterns

Pattern 1: Real-time Store + Durable Event Log

Redis Sorted Set for serving
Score events for audit/rebuild

Pattern 2: Separate Read and Write Paths

Score update path
Ranking query path

Pattern 3: Time-window Partitioning

每天 / 每周 / 每赛季使用不同 sorted sets。

Pattern 4: Regional Partitioning

降低 global hot spot。

Pattern 5: Batch Finalization

使用 offline jobs 计算 exact final ranks 和 rewards。

👉 面试回答

为了扩展 leaderboards，我会使用 Redis Sorted Sets 做 real-time ranking，持久化 score events 以支持 durability，按 time window 和 region 分区，并使用 batch jobs 计算 final ranking 和 rewards。

1️⃣6️⃣ Failure Handling

Common Failures

Score update timeout
Duplicate score submission
Redis unavailable
Event log write failure
Rank query timeout
Suspicious score submitted
Reward job partially fails

Strategies

Idempotency keys
Durable score event log
Retry score updates
从 events 重建 Redis
Fallback to cached top-N
Quarantine suspicious scores
Idempotent reward distribution

👉 面试回答

系统应该持久化 score events，这样 Redis 失败时可以重建 leaderboard。

Score submission 应该幂等， reward distribution 也必须幂等。

对 read failures，系统可以 fallback 到 cached top-N results。

1️⃣7️⃣ Consistency Model

需要较强一致性的场景

Score event persistence
Final rank calculation
Reward distribution
Anti-cheat decisions
Idempotency records

可以最终一致的场景

Real-time displayed rank
Friend leaderboard
Regional display
User profile metadata
Analytics

👉 面试回答

Real-time leaderboard display 通常可以最终一致。

用户看到自己的 rank 晚几秒更新是可以接受的。

但 final ranks 和 reward distribution 需要更强正确性。

1️⃣8️⃣ Observability

Key Metrics

Score submission QPS
Score update latency
Ranking query latency
Redis memory usage
Sorted set size
Top-N cache hit rate
Duplicate submission count
Suspicious score count
Reward job failure rate
Leaderboard rebuild time

👉 面试回答

我会监控 score submission rate、rank query latency、 Redis memory usage、sorted set size、 cache hit rate、suspicious score count、 reward job failures 和 rebuild time。

这些指标可以反映 system health 和 competition integrity。

1️⃣9️⃣ End-to-End Flow

Score Update Flow

User completes game
→ Game service validates score
→ Score event persisted
→ Leaderboard sorted set updated
→ Rank updated
→ Analytics event emitted

Ranking Read Flow

User opens leaderboard
→ Read top N from cache or Redis
→ Fetch user profile metadata
→ Return ranked list

Finalization Flow

Leaderboard period ends
→ Freeze leaderboard
→ Validate top scores
→ Compute final ranks
→ Create reward records
→ Distribute rewards
→ Archive leaderboard

Key Insight

Leaderboard System 不是简单排序用户，而是一个有 durability 和 fairness 要求的实时 ranking system。

🧠 Staff-Level Answer（最终版）

👉 面试回答（完整背诵版）

在设计 Leaderboard System 时，我会把它看作一个 real-time ranking system。

系统需要支持高吞吐 score submissions、快速 top-N queries、user rank lookup、 nearby rank queries，以及 daily、weekly、seasonal 等 time-window rankings。

对于 real-time ranking，我会使用 Redis Sorted Sets，因为它支持高效 score updates、top-N queries 和 rank lookup。

同时，我会将每次 score submission 持久化为 immutable score event，这样 leaderboard 可以被审计，也可以在需要时重建。

Leaderboard keys 应该包含 game mode、region 和 time period 等维度。

对非常大的 leaderboards，我会按 region、game mode 或 user ID 分区。

如果 exact global rank 成本太高，系统可以在线返回 approximate real-time rank，并离线计算 exact final ranks。

Score validation 很重要，因为 rewards 会激励作弊。我会尽可能 server-side validate scores，检测 suspicious submissions， quarantine abnormal scores，并在发奖前 review top ranks。

Real-time displayed rank 可以最终一致，但 final rank calculation 和 rewards 需要更强正确性。

核心权衡包括 latency、accuracy、memory cost、 rank query complexity 和 anti-cheat enforcement。

最终目标是在提供快速、有参与感的 ranking updates 的同时，保留 durable score history，保证公平竞争，并正确计算最终结果。

⭐ Final Insight

Leaderboard 的核心不是简单排序，而是一个支持实时排名、时间窗口、反作弊、最终结算和奖励发放的排名系统。