Design a LeetCode-style coding platform

Questions I would ask first: which languages and how many? Is the verdict synchronous or can the user wait a few seconds? Do contests need a live leaderboard and a fair, repeatable time limit? Are custom checkers needed (problems with many valid outputs)? Is plagiarism detection in scope? Who writes problems and test data?

Assumed scope: submit, judge against hidden tests, return a verdict (accepted, wrong answer, time limit, memory limit, runtime error, compile error), submission history, and a contest leaderboard. Out of scope: the problem editor, plagiarism detection, discussion forums, and the code editor in the browser.

These are planning figures for the exercise, not facts about any real service.

• Everyday load: 1 million daily active users × 3 submissions = 3 million a day. 3,000,000 ÷ 86,400 is about 35 a second; a 5× peak is about 175 a second.
• Contest load: 100,000 people × 6 submissions = 600,000 over 7,200 s, about 83 a second on average. Submissions cluster in the first minutes and the last ten, so plan a 10× peak: about 830 a second.
• Judge cost: assume 2 s of one core per submission (compile plus about 10 test runs). 830 × 2 = 1,660 busy cores. With 2× headroom that is 3,320 cores, about 210 workers of 16 cores each.
• Database writes: three per submission (queued row, outbox row, final verdict) = 3 × 830 = about 2,500 a second, under the 5,000 write line even if outbox cleanup adds a fourth (3,320).
• Database reads: a submission waits about 5 s and its client polls once a second, so 830 × 5 = 4,150 polls a second. A leaderboard seen by 100,000 viewers every 10 s is 10,000 reads a second, but it is served from a cached snapshot. Total about 14,000, under the 20,000 line.
• Storage: 3 million source files × 5 KB = 15 GB a day in object storage; 3 million metadata rows × 300 B = 0.9 GB a day, about 330 GB a year.

The conclusion: one relational primary is enough. The scarce resource is sandboxed CPU, so the design is about the judge fleet, its queue and its isolation, not the database.

Components. API service, submissions table (relational), object storage for source code and test bundles, a judge queue, a worker fleet, a results consumer, a leaderboard store, and a rate limiter in front of the API.

Data model. submissions(id, user_id, problem_id, language, status, verdict, runtime_ms, memory_kb, code_ref, created_at, contest_id). The primary key is a generated id; index (user_id, created_at desc) for history and (contest_id, created_at) for contest queries. Source code lives in object storage, referenced by code_ref, so rows stay small.

Write path.

1. The client posts the code with an idempotency key, so a double click returns the same submission. The limiter allows a few submissions a minute per user (a token bucket keyed by user id).
2. The API stores the source, inserts a row with status QUEUED, and writes a job to an outbox in the same transaction. A relay publishes it to the judge queue. The API returns 202 with the submission id.
3. The queue has separate lanes: contest, practice, and rejudge. Lanes keep a practice backlog from delaying a contest. Workers are pooled per language runtime, because compilers and images differ.
4. A worker takes a job with a lease, runs it in the sandbox, and writes the verdict with a conditional update (where status != 'DONE'). If the worker dies, the lease expires and the job is retried. Judging is repeatable apart from borderline time limits, and the conditional update keeps the first verdict, so a second run changes nothing.
5. A results consumer updates the leaderboard on accepted verdicts, de-duplicated by submission id and counting only a user's first accepted submission per problem, so a replayed event changes nothing.

Read path. The client polls the submission by id with backoff, or listens on a server-sent stream. The leaderboard is a sorted set keyed by (problems solved, penalty), rebuilt from the table if lost.

Hard problem 1: running untrusted code. Assume every submission is hostile. Run it in a container hardened with a seccomp syscall filter, no network, a read-only root, a small writable tmpfs, an unprivileged user, and cgroup limits on CPU, memory, process count and output size. Containers share the host kernel, so for a stronger boundary use a user-space kernel sandbox or a microVM, and accept the startup cost and syscall overhead. Never run code in the API process, and never give the sandbox credentials. Wipe the sandbox after every run, so one submission cannot leave anything for the next.

Hard problem 2: fair verdicts under burst. Wall-clock limits are noisy on shared machines. Pin each run to a core, enforce CPU-time limits as well as wall time, and re-run a borderline time-limit failure once before reporting it. The contest start time is known, so scale the fleet and pre-pull test bundles (about 10 problems × 10 MB each) before it begins, instead of reacting to queue depth. Stop a test run at the first failure for practice submissions, and run all tests in a contest only if scoring needs it.

• Container vs microVM sandbox. Containers start in milliseconds but share the kernel, so one kernel bug can escape. A microVM or user-space kernel isolates better and costs more per run. Pick the stronger boundary for a public platform running arbitrary code; flip to plain hardened containers only for a closed internal tool.
• Polling vs push for verdicts. Polling is stateless and survives restarts; push saves requests but needs long-lived connections. With about 4,000 polls a second, polling is fine; flip to a stream when waiting clients reach the hundreds of thousands.
• Queue autoscale vs scheduled scale. Reactive scaling lags a burst by minutes, which is exactly how long a contest start lasts. Pre-scale from the contest schedule, and keep reactive scaling for the unscheduled practice load.
• Stop at first failure vs run every test. Stopping saves CPU; running all gives partial-credit scoring and better feedback. Stop early for practice, run all where scoring demands it.

• Running submitted code on the API servers or in a shared process, and treating sandboxing as a detail.
• Sending everything through one queue, so a practice backlog delays a contest.
• Sizing the database carefully and never sizing the judge fleet, which is the real bottleneck.
• Using wall-clock time only, then getting flaky time-limit verdicts from noisy neighbours.
• Writing every state change straight to the database, or storing source code as large blobs in the primary table.
• Skipping idempotency and rate limits, so a double click or a script floods the queue.
• Leaking hidden test inputs or expected outputs in error messages.