← Meta Interview Insights

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

SeniorPrefer not to say
May 2026

Summary

System design round at Meta for a software engineer role. The whole session was basically one big leaderboard problem, which sounds contained until you realize how many directions it can go.

Questions Asked (1)

Q1

Design a leaderboard system for a multiplayer game that supports a global top-10, a friends-filtered top-10, real-time score updates, and optional rank queries at scale.

System DesignTechnical Trade-offsAlgorithms & Data Structures
Author's notes

I jumped straight to Redis sorted sets which felt right, and they didn't push back on that.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., number of players, updates per second, read patterns), then propose a high-level architecture using a fast in-memory sorted set for global leaderboards and a separate service for friends filtering. Discuss data partitioning, consistency models, and trade-offs between accuracy and latency for real-time updates and rank queries.

Pro tip: Emphasize that leaderboards are read-heavy with occasional writes, so optimize for reads using caching and precomputed rankings; also mention that friends leaderboards can be computed on-demand by intersecting friend lists with the global leaderboard, avoiding separate storage.

1. Clarify Requirements and Scale

Ask questions to understand the expected number of players, frequency of score updates, read/write ratio, latency requirements, and whether rank queries need to be exact or approximate. This sets the stage for design decisions.

2. High-Level Architecture

Propose using an in-memory data store like Redis with sorted sets for the global leaderboard, and a separate service for friends leaderboards. Discuss how to handle real-time updates via a pub/sub or streaming pipeline.

3. Data Partitioning and Sharding

Explain how to partition the leaderboard data across multiple nodes to handle scale, using techniques like consistent hashing or range partitioning. Address how to maintain a global top-10 across shards.

4. Real-Time Updates and Consistency

Describe the write path: score updates are written to a durable store (e.g., database) and then asynchronously propagated to the in-memory leaderboard. Discuss trade-offs between strong and eventual consistency.

5. Rank Queries and Friends Filtering

Explain how to efficiently compute a player's rank using sorted set operations (e.g., ZREVRANK) and how to generate a friends leaderboard by fetching the player's friend list and querying their scores, possibly using a cache.

Key Points to Mention

  • Use of Redis sorted sets (ZSET) for O(log N) insertions and rank queries.
  • Sharding strategies for horizontal scaling, such as partitioning by player ID range or hash.
  • Trade-offs between strong consistency (e.g., using a database with transactions) and eventual consistency (e.g., using a cache with async updates).
  • Caching strategies for hot leaderboards (e.g., global top-10) to reduce load on the primary data store.
  • Handling friends leaderboard efficiently by intersecting friend lists with the global leaderboard, possibly using a graph database or precomputed friend scores.
  • Approaches for approximate rank queries (e.g., using probabilistic data structures) when exact ranks are too expensive.

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