Designing a Secure LeetCode Submission Service with Per-Problem Time Limits

Requirements for a Secure Code Execution Service

The core requirements are enforcing per-problem time limits, isolating untrusted user code across various language runtimes, balancing load efficiently, and maintaining data integrity through short-lived caching.

Minimal Viable Design: Queue-Driven Workers

The smallest functional design uses a prioritized queue feeding short-lived, containerized worker pools. An auto-scaling controller manages the judge instances to meet latency demands during traffic spikes.

Trust and Data Boundaries

User code is entirely untrusted. Isolation is achieved using containers per language, which must be configured without network or filesystem access beyond explicit, minimal allowances. Problem metadata and language images must be versioned; the cache layer uses a short Time-To-Live (TTL) and invalidates immediately upon version change.

Operational Checks and Verification

Monitor CPU, memory, latency, and critically, sandbox escape attempts. Verification requires confirming time limit enforcement and verifying that malicious calls (e.g., file I/O) are blocked within the container.

Concrete Example: Enforcing Time Limits

To verify the 2-second limit, run the following command on the judge host/cluster environment:

docker run --rm -v $(pwd)/bench:/work -e TIME_LIMIT=2 python:3.11-slim /bin/sh -c "time python -c 'import time; time.sleep(1.5)'"

This confirms the judge correctly terminates the process before the limit is reached. Permissions required are those necessary to run containers (e.g., root or specific pod-security-context privileges).

Failure Modes and Design Triggers

False failures due to language-specific garbage collection pauses are mitigated by allowing per-submission time overrides alongside a modest default. Design changes are triggered by sustained SLA breaches (requiring more aggressive scaling) or the introduction of new, unsupported language runtimes.

Practical Verification Check

To check the cache integrity after an update, update a problem statement, submit a test case, and verify the subsequent request results in a cache miss on the backend, confirming prompt invalidation.