##### Question This Meta onsite system-design round asks you to design two large-scale systems back to back. Cover end-to-end architecture, APIs, data models, storage choices, sharding/partitioning, consistency, scale estimates, and operational considerations for each. **A) Leaderboard service (large-scale game)** 1. Compute a user's **global rank** and their **rank within their friendship circle**. 2. Retrieve the **k users immediately before and after** a given user, both globally and within the friend circle. 3. Support **top-N paginated** queries with stable pagination windows. 4. Handle **high write rates** (frequent score updates), caching, and consistency trade-offs. 5. Integrate the **friend graph** and handle large friend lists efficiently. 6. Support **anti-cheat / integrity** (server-authoritative scoring, anomaly detection). 7. Support **seasonal resets** and **multi-game / multi-mode** leaderboards. 8. Provide **backfill / batch** workflows for recovery and recomputation. Detail APIs, data models (e.g., sorted sets and secondary indexes), sharding/partitioning, caching, consistency, ranking computation, and how ties are broken. **B) Real-time messenger application** 1. Support **1:1 and group chat** (including very large groups). 2. Guarantee correct **per-conversation message ordering**. 3. Choose and **justify a delivery guarantee** (at-least-once / at-most-once / exactly-once). 4. Support **online presence**, **typing indicators**, and **read/delivery receipts**. 5. Support **media sharing** and **push notifications**. 6. Support **end-to-end encryption (E2EE)**. 7. Support **offline sync** and **multi-device** consistency. 8. Handle **fanout for large groups**. 9. Provide **spam/abuse controls** and **disaster recovery**. Provide an end-to-end architecture, storage choices, protocols, scale estimates, and operational considerations.

Design leaderboard and messenger systems evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Meta.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Meta during technical interviews.

Design leaderboard and messenger systems

This Meta onsite system-design round asks you to design two large-scale systems back to back. Cover end-to-end architecture, APIs, data models, storage choices, sharding/partitioning, consistency, scale estimates, and operational considerations for each.

A) Leaderboard service (large-scale game)

Compute a user's global rank and their rank within their friendship circle .
Retrieve the k users immediately before and after a given user, both globally and within the friend circle.
Support top-N paginated queries with stable pagination windows.
Handle high write rates (frequent score updates), caching, and consistency trade-offs.
Integrate the friend graph and handle large friend lists efficiently.
Support anti-cheat / integrity (server-authoritative scoring, anomaly detection).
Support seasonal resets and multi-game / multi-mode leaderboards.
Provide backfill / batch workflows for recovery and recomputation.

Detail APIs, data models (e.g., sorted sets and secondary indexes), sharding/partitioning, caching, consistency, ranking computation, and how ties are broken.

B) Real-time messenger application

Support 1:1 and group chat (including very large groups).
Guarantee correct per-conversation message ordering .
Choose and justify a delivery guarantee (at-least-once / at-most-once / exactly-once).
Support online presence , typing indicators , and read/delivery receipts .
Support media sharing and push notifications .
Support end-to-end encryption (E2EE) .
Support offline sync and multi-device consistency.
Handle fanout for large groups .
Provide spam/abuse controls and disaster recovery .

Provide an end-to-end architecture, storage choices, protocols, scale estimates, and operational considerations.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?