Algocode

[Framing]

The fix was Linux isolation primitives. Namespaces for filesystem and process isolation. cgroups for CPU and memory caps. seccomp to whitelist the syscalls a C++ judge actually needs, since the syscall surface for a C++ binary is small and predictable. Each submission gets a sibling container that lives only as long as the submission, with hard wall-clock limits and a hard syscall allowlist.

[Build]

The system splits into three independently deployable services. Auth handles user management and tokens. Code Manager is the public-facing API. It validates the user, writes the submission to its own database, and publishes an event to RabbitMQ tagged by language. RCE Engine consumes from its language-specific queue and runs the judge in the hard-isolated sibling container. Results publish back via a unified RabbitMQ result queue, and Code Manager caches in Redis and persists to Mongo.

[Deploy]

The whole thing runs on free-tier AWS EC2 plus an Azure VM (1GB RAM each), which is why the rate-limit middleware exists. Three submissions per minute per user, via Token Bucket. I built the limiter in Django Middleware rather than reaching for an API gateway, because adding cloud spend for one feature felt wrong. The split into three repos (algocode-auth, code-manager, rcee) was deliberate. Independent deploys and independent failures.

[What's next]

What's next, if I pick this back up. Skip Mongo for results and use Postgres JSONB, one less service to operate. Build a frontend. Add Java and Python judges (the RCE Engine stubs are in place). The rate-limit logic deserves a small dashboard so I can see who's hitting it.