Design a coding contest platform that allows users to view problems, submit code, and compete in real-time programming contests. The system should support high traffic volume, with approximately 100 million daily active users (DAU), and handle intense load during peak contest times.
Functional Requirements
Let’s define what our coding contest platform must support:
- View Problems: Users should be able to browse, search, and filter coding problems by tags, difficulty, company, or topic
- Submit Code: Users should be able to write and submit code in a browser-based editor with support for multiple languages
- Contests with Live Leaderboard: Users should be able to participate in real-time contests with auto-evaluation and dynamic leaderboard updates
- View Submissions & Results: Users should be able to see the status of their submissions (e.g., passed, failed, runtime error) and access past attempts
Non-Functional Requirements
The system must be robust, scalable, and performant under heavy traffic:
- 50k+ Concurrent Contestants: Handle large-scale contests with tens of thousands of users submitting simultaneously
- Low Latency Leaderboard Updates: Update rankings in near real-time (within 10 seconds) to ensure fairness and competitiveness
- Secure and Sandboxed Code Execution: All submitted code must run in isolated, rate-limited containers to prevent malicious behavior
- Fast Code Judging Pipeline: Code submissions should be evaluated within a few seconds to ensure a responsive user experience
- High Availability: The system should remain responsive during peak usage with strong fault tolerance and graceful degradation
API Design
We'll define RESTful endpoints for problem browsing, code submission, and contest functionality:
// Get detailed problem information
GET /problems/:problemId
Response:
{
"problemId": "p123",
"title": "Two Sum",
"description": "Find two numbers that add up to a target value.",
"difficulty": "Easy",
"tags": ["array", "hashmap"],
"sampleTests": [
{
"input": "nums = [2, 7, 11, 15], target = 9",
"output": "[0, 1]"
}
]
}
// Get a paginated list of problems
GET /problems?offset=0&limit=50
Response:
{
"problems": [
{ "problemId": "p123", "title": "Two Sum", "difficulty": "Easy" },
{ "problemId": "p124", "title": "Reverse Linked List", "difficulty": "Medium" }
],
"total": 2400
}
// Submit code for a specific problem
POST /submit/:problemId
Request:
{
"code": "def twoSum(nums, target): ...",
"language": "python"
}
Response:
{
"submissionId": "s456",
"status": "Pending"
}
// Get a paginated list of contest problems
GET /contests/:contestId?offset=0&limit=50
Response:
{
"contestId": "c001",
"title": "Weekly Contest 101",
"problems": [
{ "problemId": "p201", "title": "Minimum Path", "difficulty": "Medium" },
{ "problemId": "p202", "title": "Binary Gap", "difficulty": "Easy" }
]
}
Core Entities
- User: A registered participant who can attempt problems and compete in contests
- Problem: A coding challenge with description, constraints, sample tests, and metadata
- Submission: A user's code submission, including source code, language, result, and timestamps
- Contest: A time-bound event consisting of multiple problems and a competitive leaderboard
- Leaderboard: A real-time scoreboard showing user rankings based on contest performance
High-Level Design
To support secure and scalable code execution along with real-time leaderboard updates, our system needs strong isolation, precise resource limits, and efficient data modeling.
Execution Sandbox Requirements
- Security / Isolation: Each code submission must run in a secure container with no access to other user processes
- Resource Limits: Enforce strict caps on memory, execution time, and CPU usage per submission
- No Network or Filesystem Access: Block outbound network calls and restrict file read/write access to prevent abuse
Leaderboard Aggregation Query
SELECT user_id, SUM(s.points) as points
FROM submissions AS s
WHERE s.contest_id = {123}
GROUP BY user_id
ORDER BY points DESC;
Core Data Models
// Contest
Contest {
id: string,
problem_id: string[], // List of problems in the contest
points: int[] // Points assigned per problem
}
// Submission
Submission {
id: string,
user_id: string,
problem_id: string,
contest_id?: string,
points?: int,
passed: boolean
}
Deep Dives
Redis Sorted Set
In-memory data structure store, using ZSET for leaderboard
How it works:
Uses a sorted set data structure to maintain scores. Each user is a member of the set, with their score as the sorting criteria
Pros:
- Extremely fast read and write operations
- Built-in ranking and range queries
- Scalable and can handle high concurrency
Cons:
- Data is volatile (in-memory), requiring persistence strategies
- May require additional infrastructure setup
Conclusion:
Highly suitable for real-time leaderboards with frequent updates and queries
Hope this gives you a clear idea of how platforms like LeetCode are built behind the scenes!
