Design a Competitive Programming Platform

A competitive programming platform like Codeforces or LeetCode is fundamentally a code execution service with a real-time ranking system. Users write code, the platform runs it against hidden test cases inside a sandbox, and the results drive a live leaderboard. What makes this problem interesting is the tension between two opposing demands: you need airtight security (running arbitrary user code is inherently dangerous) and you need speed (contestants expect verdicts within seconds during a timed competition).

The core loop: a user submits code, the system compiles and executes it inside an isolated container, compares the output against expected answers for each test case, produces a verdict (Accepted, Wrong Answer, Time Limit Exceeded, Memory Limit Exceeded, or Runtime Error), and updates the contest leaderboard. Every design decision serves this loop.

Functional

Traffic

During a popular contest, the platform handles 100,000 concurrent users. At peak, typically the first 30 minutes when everyone starts submitting, traffic reaches 5,000-10,000 submissions per minute. Each submission triggers a full evaluation cycle: container creation, compilation, execution against 10-50 test cases, and result storage.

Outside of contests, traffic drops dramatically. Practice submissions might average 100-500 per minute. The 100x traffic ratio between contest peak and normal operation drives the need for elastic scaling.

Submit Code

1POST /api/submissions
2Headers: Authorization: Bearer \<token>
3Body: {
4"problemId": "prob_123",
5"contestId": "contest_456",
6"language": "cpp",
7"sourceCode": "#include \<iostream>\nint main() { ... }"
8}
9Response: 202 { "submissionId": "sub_789", "status": "queued" }

The response is 202 Accepted (not 201 Created) because the submission is queued for evaluation, not yet processed. The contestId is optional, null for practice submissions. The client polls for the verdict or subscribes via WebSocket.

Users Table (PostgreSQL)

1users
2├── user_id UUID PRIMARY KEY
3├── username VARCHAR(20) UNIQUE NOT NULL
4├── email VARCHAR(255) UNIQUE NOT NULL
5├── password_hash VARCHAR(255) NOT NULL
6├── rating INTEGER DEFAULT 1500
7├── max_rating INTEGER DEFAULT 1500
8└── created_at TIMESTAMP NOT NULL

PostgreSQL for all structured data. The rating field is updated after each contest via the rating algorithm. The max_rating tracks the user's peak rating for display purposes (colored usernames on Codeforces correspond to max_rating tiers).

The architecture centers on a job queue that decouples submission ingestion from evaluation. This is the key architectural decision, without the queue, a burst of 10,000 submissions per minute would overwhelm the evaluation workers directly. The queue absorbs the burst and feeds workers at a sustainable rate.

Frontend (React or Angular) provides the code editor, problem browser, contest dashboard, and live leaderboard. It communicates with the backend exclusively through the API Gateway, which handles authentication (JWT validation), rate limiting (per-user submission throttle), and request routing to microservices.

Submission Evaluation Flow

This is the core flow, from code submission to verdict. Every design decision in the architecture serves this path.

Docker Sandbox Execution Engine (GATE)

The execution engine is the most security-critical and performance-sensitive component. It runs arbitrary user code safely while producing fair, reproducible verdicts.

Real-Time Leaderboard vs Consistent Leaderboard

A Redis-cached leaderboard provides sub-millisecond reads at 20,000 QPS but may show briefly stale rankings. The staleness window is tiny (milliseconds between a verdict arriving and Redis being updated), but during a contest with thousands of concurrent submissions, two users might see different rankings for a moment.

A database-consistent leaderboard always shows the correct state but cannot handle 20,000 reads per second without extensive read replicas. During a contest, the latency would increase from sub-millisecond (Redis) to 5-50ms (PostgreSQL), which compounds when 100,000 users are polling.

Evaluation Worker Failure

A worker crashes mid-evaluation, the Docker container is killed and the submission result is lost. The system must recover without losing the submission or producing an incorrect verdict.

AI-Powered Problem Recommendations

Current problem browsing is manual, filter by difficulty and tags. An AI recommendation engine could analyze a user's submission history to identify weak areas (graph algorithms, dynamic programming, number theory) and suggest targeted practice problems. This requires a feature store tracking per-user performance by topic, a recommendation model trained on the community's learning patterns, and an A/B testing framework to measure whether recommendations improve skill growth.

Code Plagiarism Detection