A global leaderboard for a game with 500 million players across 20 countries needs to aggregate scores from everywhere. A player in Mumbai competing for rank 1 globally is competing against a player in São Paulo. The data is split across regional deployments for latency reasons. Combining it without introducing consistency problems is the interesting part.

Why Regional Splits Exist#

Storing all player scores in one region means cross-region write latency for score updates. Players in Europe writing scores to US-East adds 100-150ms to every match result submission. For a competitive game, that delay matters. So most large games run regional leaderboard instances: EU players update the EU leaderboard, APAC players update the APAC leaderboard.

Regional Leaderboards Are Easy#

Within a region, a single sorted set (or a sharded one, as discussed yesterday) handles regional rankings. Latency is low, writes are local, reads are fast. “Top 100 in Europe” is a simple query on the EU sorted set.

Global Roll-Up#

Combining regional leaderboards into a global one has multiple approaches.

Periodic batch roll-up: every 15 minutes, a job reads top-N from each region, merges them, and writes the result to a global leaderboard store. The global leaderboard is always N minutes stale. Fine for most games.

Continuous roll-up: every score update also publishes an event to a global aggregation stream (Kafka or equivalent). A stream processor maintains a global sorted set by consuming from all regional streams. Lower latency, but requires a stream processing pipeline.

graph TD A[EU Score Update] --> B[EU Leaderboard] C[APAC Score Update] --> D[APAC Leaderboard] E[US Score Update] --> F[US Leaderboard] B -->|periodic export| G[Global Aggregator] D -->|periodic export| G F -->|periodic export| G G --> H[Global Leaderboard: merged top-N] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

The Stale Global Rank Problem#

With regional splits, a player’s global rank is always a function of stale data. You can show “based on scores updated in the last 15 minutes.” Players generally accept this. Rank 1 globally is stable enough that 15-minute staleness doesn’t matter. The exception is the end of a competitive season: players grinding rank in the final hour need freshness. You switch to continuous roll-up for the last few hours of a season.

Friend Leaderboards#

Most competitive games show a leaderboard of your friends specifically, not global rank. A friend leaderboard for 200 friends is trivially fast: look up all friend scores in parallel, sort locally. This doesn’t require any of the sharding or aggregation complexity of the global leaderboard. It’s also more engaging than a global list where you’re rank 3 million.

At Oracle#

Our telecom KPIs were aggregated per region and then rolled up to national dashboards. Regional aggregation ran every 5 minutes. National roll-up ran every 15 minutes. When operators complained that the national dashboard lagged the regional one, we found that the roll-up job was waiting for all regions to complete before merging. One slow region delayed the national view. We changed to merge whatever was available at the 15-minute mark and flag stale regions. Partial freshness was better than complete staleness.

What I’m Learning#

Global aggregation from regional data always involves a freshness trade-off. Making that trade-off explicit in the UI (“updated X minutes ago”) is better than hiding it. Users trust a system that tells them when data is stale more than one that silently serves old data.

Have you built roll-up aggregations across distributed data sources, and how did you handle regions that were consistently slow to report?