Design an Online Coding Competition Platform

# Design an Online Coding Competition Platform Design a service where participants submit code, run it in a secure sandbox, receive a score, and view a near-real-time leaderboard. The main leaderboard shows the top 100, while every participant must be able to retrieve their own exact rank even when outside that set. ### Constraints & Assumptions - Submissions contain untrusted code in several languages. - A contest defines problems, test versions, scoring rules, and start/end times. - A user may submit repeatedly; the scoring rule chooses which attempt counts. - Ranking must use an explicit deterministic tie-break. - Execution demand is bursty near contest deadlines. ### Clarifying Questions to Ask - Is score based on correctness, runtime, points per test, or a combination? - Which tie-break determines rank among equal scores? - How fresh must the leaderboard be? - Are practice runs and scored submissions separate? ### Part 1 - Submission and sandbox execution Define the submission API, durable queue, compiler/executor isolation, resource limits, test access, and result state machine. #### What This Part Should Cover - Immutable source and problem-version binding - Network and filesystem isolation - Time, memory, process, and output limits - Idempotent jobs and retry policy ### Part 2 - Scoring and leaderboard Design score aggregation, top-100 serving, exact personal rank, tie-breaking, and update semantics. #### What This Part Should Cover - Canonical ranking tuple - Efficient top-k and rank queries - Versioned score updates - Eventual-consistency bounds and reconciliation ### Part 3 - Scale, fairness, and abuse Discuss burst control, worker pools, language isolation, plagiarism or submission abuse, observability, and contest finalization. #### What This Part Should Cover - Admission control and fair scheduling - Capacity isolation by language or job class - Auditability and rejudge support - Freeze and final-rank consistency ```hint Rank by a complete tuple A score alone does not define a unique order. Include the contest's tie-break fields and participant ID so top-100 and personal-rank queries agree. ``` ### What a Strong Answer Covers - A safe, reproducible untrusted-code execution boundary - Durable submission and scoring states with exact version binding - A ranking design that supports both top 100 and arbitrary self-rank - Burst handling, fairness, rejudging, and finalization controls ### Follow-up Questions 1. How would you rejudge every submission after a bad test case is corrected? 2. How can a participant's rank be returned without scanning all scores? 3. What prevents a compile bomb from reducing capacity for every language?