← Meta Interview Insights

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

Senior
Jul 2026

Summary

System design round at Meta for a software engineering role. The question was a full leaderboard design problem, which sounds straightforward until you actually have to think through all the edge cases at scale.

Questions Asked (1)

Q1

Design the backend system for an online game leaderboard that supports high write volume, global and friends-based rankings, a player's rank with nearby players, multiple time windows (daily, weekly, all-time), and low-latency reads at scale.

System DesignTechnical Trade-offsData Modeling
Author's notes

This one covers a lot of ground and I think I underestimated how many sub-problems are buried inside it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale (e.g., writes per second, read latency, number of players). Then propose a high-level architecture that separates write ingestion from read serving, using a fast in-memory store for real-time rankings and a durable store for persistence. Finally, dive into data modeling and trade-offs for global vs. friends rankings and multiple time windows.

Pro tip: Emphasize that leaderboards are read-heavy and latency-sensitive, so you should decouple writes from reads using a streaming pipeline (e.g., Kafka) and maintain pre-aggregated views. Also, discuss how to handle rank queries efficiently by using sorted sets with score-based pagination.

1. Clarify Requirements and Scale

Ask questions to understand the expected write QPS, read QPS, latency requirements, number of players, and update frequency. Clarify what 'friends-based rankings' means (e.g., mutual friends, one-way follows) and how time windows are defined.

2. High-Level Architecture

Propose a system that ingests score updates via a message queue (e.g., Kafka) and processes them with a stream processor (e.g., Flink) to update multiple leaderboards. Use a fast in-memory data store (e.g., Redis) for serving rankings and a durable store (e.g., Cassandra) for persistence and recovery.

3. Data Modeling and Ranking Logic

Model each leaderboard as a sorted set in Redis, with player ID as member and score as value. For time windows, use separate keys with TTL or periodic snapshots. For friends rankings, maintain per-player friend lists and compute rankings on the fly or precompute using a graph store.

4. Handling Player Rank and Nearby Players

Use Redis ZREVRANK to get a player's rank and ZRANGE to fetch nearby players. For scalability, consider sharding by leaderboard ID or using a tiered approach where top N are cached and the rest are computed on demand.

5. Trade-offs and Optimizations

Discuss trade-offs between consistency and latency (e.g., eventual consistency for friends rankings), cost of maintaining multiple time windows, and strategies for hot keys (e.g., sharding popular leaderboards). Mention monitoring and auto-scaling.

Key Points to Mention

  • Use of Redis sorted sets for O(log N) rank queries and efficient range retrieval.
  • Stream processing (e.g., Kafka + Flink) to decouple writes and update multiple leaderboards asynchronously.
  • Time windows: separate keys with TTL or periodic snapshots to avoid recomputing from scratch.
  • Friends rankings: precompute per-player friend lists and either compute on read or maintain separate sorted sets per user.
  • Sharding and replication strategies to handle high write volume and low-latency reads at scale.
  • Trade-offs: consistency vs. latency, cost of maintaining multiple leaderboards, and handling hot keys.

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