Code execution sandbox - running a stranger's program

Why this design

This is the system behind every online judge, coding interview pad and "run" button in a tutorial. It is asked because it combines two hard things that usually live in different teams: security isolation against a workload that is actively hostile, and queueing under a demand curve that has a cliff in it every time a contest starts. Candidates usually spend the whole hour on Docker flags. The interesting answer spends half of it on the queue.

What you will learn

• Why a container is not a sandbox for untrusted code, and what a microVM (Firecracker, roughly 125 ms cold boot and under 5 MiB of overhead) buys over gVisor and plain namespaces.
• The limits every run gets - CPU time, wall time, memory, processes, output bytes, no network - and which of them actually stop which attack.
• Why one VM per run, never reused, and how a warm pool of snapshot-restored VMs pays for that rule.
• Why the queue is the system: admission, per-user fairness, leases, and why autoscaling cannot catch a contest spike.
• Why verdicts near the time limit are not reproducible, and the three things that make them less wrong.

How to read this board

1. Press Play. A submission arrives TOP LEFT, is admitted, and lands in THE QUEUE at the bottom left.
2. The scheduler leases it, takes a warm VM and places it on a host in SCHEDULE AND ISOLATE.
3. The watchdog enforces the limits; the judge compares output on the RIGHT and the verdict is pushed back.
4. Then pages 1 to 6, and the DATA MODEL under them.
5. Argue with the weaknesses: the contest spike the autoscaler cannot catch, the idle warm pool, and the 1.95-second solution that passes on Tuesday.

Ask these before drawing anything

• Judge or playground? A judge runs a fixed program against hidden test cases and returns a verdict. A playground runs interactively with stdin and maybe a terminal. They share isolation and differ in everything else; this board is a judge.
• Which languages? Each one is a root filesystem image with its own startup cost - C++ is ready in 5 ms, the JVM needs 400 ms before main(), and that startup must not count against the user's time limit.
• Is the time limit CPU time or wall time? CPU time is fairer; wall time catches the program that sleeps or blocks. Use both: CPU for the verdict, wall as the kill.
• Does user code ever need the network? For a judge, no - and "no network device at all" is far stronger than a firewall rule.
• Are there scheduled contests? A known spike can be pre-warmed. An unknown one cannot.

Functional

• Accept a submission (source, language, problem) and return a verdict per test case: Accepted, Wrong Answer, Time Limit, Memory Limit, Runtime Error, Compile Error.
• Report CPU time and peak memory per test case.
• Submitting twice with the same idempotency key creates one submission.
• Push the verdict to the browser; polling is a fallback.

Non-functional

• No submission can read another submission's code, output or test cases, reach the network, or affect the host. This outranks every other requirement.
• Queue wait p95 under 2 s on a normal day, under 30 s during a contest peak.
• A host dying mid-run loses no submission; it is re-run elsewhere.
• Per-user fairness: one user submitting 500 times cannot delay another user's single submission.

Out of scope

• Plagiarism detection.
• Interactive debuggers and terminals.
• GPU workloads.