Meta·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Jul 2026

Summary

Meta system design round focused entirely on a real-time leaderboard for an online game. The scope was well-defined but there were enough moving parts (global vs regional queries, rank neighbors, anti-cheat) that it kept me busy the whole session.

Questions Asked (1)

Design a real-time leaderboard system for an online game where players submit score updates frequently, and the system needs to support querying the top N players both globally and by region, as well as a player's current rank and nearby neighbors, all with low latency.

System DesignTechnical Trade-offsData Modeling

Author's notes

I went straight to Redis sorted sets and they seemed fine with that direction, but I fumbled a bit when they pushed on regional breakdowns.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements: scale (QPS, number of players), latency targets, consistency needs, and regional definitions. Then propose a high-level architecture using a fast in-memory store (e.g., Redis sorted sets) for global and per-region leaderboards, with a write path that updates scores and a read path that serves top-N, rank, and neighbors. Discuss trade-offs around consistency, sharding, and caching.

Pro tip: Emphasize that leaderboards are read-heavy and can tolerate eventual consistency; use Redis sorted sets with periodic snapshots to a durable store, and consider approximate ranking for massive scale to avoid O(log N) updates on every score change.

1. Clarify Requirements and Scale

Ask about number of players, score update frequency, read QPS, latency targets, and consistency requirements. Define what 'region' means and whether leaderboards are per-region or global with regional filters.

2. High-Level Architecture

Propose a write path: score updates go to a message queue (e.g., Kafka) for buffering and then to a stream processor that updates leaderboards. Read path: API servers query an in-memory data store (e.g., Redis) for top-N, rank, and neighbors.

3. Data Modeling and Storage

Use Redis sorted sets for each leaderboard (global and per-region). Score updates use ZADD, top-N uses ZREVRANGE, rank uses ZREVRANK, and neighbors use ZREVRANGE around the player's rank. For durability, periodically snapshot to a database like Cassandra or DynamoDB.

4. Scaling and Sharding

Shard leaderboards by region and possibly by player ID ranges to distribute load. Use consistent hashing to route requests. For global leaderboard, aggregate regional top-N lists or use a separate global sorted set updated asynchronously.

5. Trade-offs and Optimizations

Discuss consistency vs. latency: eventual consistency is acceptable for leaderboards. Consider approximate ranking (e.g., using t-digest) for very large scale. Cache top-N results with short TTL. Handle hot keys by replicating or sharding further.

Key Points to Mention

Use of Redis sorted sets for O(log N) updates and O(log N + M) range queries.
Asynchronous processing via message queue to decouple score submission from leaderboard updates.
Sharding by region and player ID to scale horizontally.
Trade-off between strong consistency and low latency; eventual consistency is acceptable.
Periodic snapshots to durable storage for fault tolerance.
Caching top-N results and using approximate algorithms for massive scale.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.