##### Question Design a coding platform (e.g., LeetCode) that supports problem execution at scale and provides a live global leaderboard; address test-case storage, execution orchestration, message-queue fault tolerance, and scalability considerations.

Design coding platform leaderboard system 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 coding platform leaderboard system

System Design: Scalable Coding Platform with Live Global Leaderboard

Context

Design a coding challenge platform (similar to LeetCode) where users submit code to be compiled and executed against test cases at scale. The system must provide a live global leaderboard that updates in near real time.

Assume:

Millions of users, with peak submission bursts (e.g., during contests).
Multiple languages/runtimes (e.g., Python, Java, C++), each with time/memory limits.
Hidden and public test cases; hidden cases must never be leaked to clients.
Fairness and isolation: untrusted user code must run in sandboxed environments.

Requirements

Design the system to address:

Test-case storage and distribution to executors.
Execution orchestration (compile, run, shard across test cases, aggregate results).
Message-queue fault tolerance (retries, idempotency, DLQs, ordering where needed).
Scalability and elasticity across services.
Live global leaderboard with low-latency updates.

Call out key APIs, data models, high-level architecture, 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?