Design an Online Code Judge (LeetCode)

#Problem Statement

Design an online judge where users submit code solutions to algorithmic problems. The system compiles and runs the code against test cases, and returns whether the solution is correct (pass/fail) along with performance metrics.

📖

Real-world & security angle: This is the purest "run untrusted code safely" problem in the catalog — it's literally arbitrary code from strangers, so it's a security design first and a queue design second. The whole game is sandboxing: you cannot run submissions on a normal host, so you isolate each run in a throwaway container or, better, a stronger boundary like gVisor or a Firecracker microVM (the same untrusted-workload tooling from ../kubernetes/fundamentals.md), with no network, dropped capabilities, a read-only filesystem, and hard CPU/memory/time limits to stop fork bombs, crypto-miners, and attempts to read other users' submissions or the test answers. Real judges have been escaped — contestants have read the expected outputs or broken out of weak sandboxes — which is exactly why defense-in-depth matters. Architecturally it's a submission queue → isolated worker pool → results via WebSocket, but if you don't lead with isolation, you've failed the question.

#Requirements

#Functional

• Users submit code in multiple languages (Python, Java, C++, Go, etc.)
• Run code against hidden test cases
• Return: pass/fail per test case, runtime, memory usage
• Problem library with description, constraints, examples
• Submission history

#Non-Functional

• 500k submissions/day → ~6 submissions/s average; 100/s peak during contests
• Execution timeout: configurable per problem (typically 1-5 seconds)
• Sandboxed execution — user code must not access the host filesystem, network, or other processes
• Consistent results: same code → same result

#Core Design

#The Critical Requirement: Sandboxed Execution

Running arbitrary user-submitted code is one of the most dangerous operations in systems design. The execution environment must be completely isolated.

Approaches (security level low → high):

1. Docker container per submission — run code in a minimal container. Container limits CPU, memory, network. Cheap but not foolproof (container escapes possible with kernel bugs).

2. gVisor (Google's userspace kernel) — intercepts syscalls before they reach the real kernel. Better isolation than Docker alone. Used by Google's judge (Codeforces uses it).

3. Firecracker microVM — lightweight VM (100ms startup). True hypervisor isolation. Used by AWS Lambda. Each submission = fresh microVM.

4. WASM sandbox — compile to WebAssembly; runs in a wasm runtime with no OS access. Very safe but language support is limited.

For the interview, describe Docker + seccomp + resource limits:

Docker run options:
  --cpus=1
  --memory=512m
  --network=none          # no internet access
  --read-only             # read-only filesystem
  --security-opt seccomp=restricted.json  # block dangerous syscalls
  --pids-limit=100        # no fork bombs
  --no-new-privileges

#Queue-Based Execution

User submits code → API → Submission DB (PENDING) → Job Queue (Kafka/SQS)
                                                           ↓
                                                   Execution Workers
                                                   (auto-scaling pool)
                                                           ↓
                                          Spin up container → compile → run test cases
                                                           ↓
                                          Update Submission DB (ACCEPTED/WA/TLE/MLE/RE)
                                                           ↓
                                          Notify user (WebSocket)

#Execution Result Codes

#Contest Mode (High Burst)

During contests, thousands of submissions arrive simultaneously. Queue absorbs the burst; workers scale out (Kubernetes HPA). Worker pool should be pre-warmed — starting a cold container takes 200ms+.

Worker warm poolmaintain N pre-started containers ready to receive code. After execution, re-initialize the container (or discard and start fresh from image).

#Security Considerations

Security engineering notethis is an excellent real-world example of sandboxed execution that comes up in security interviews. The design maps directly to how CI/CD runners, Lambda functions, and browser DevTools sandboxes work.

#Interview Tips