What makes DevForces different ?
Every competitive platform tests algorithmic thinking. None of them test what backend engineers actually do: build HTTP APIs that handle auth, validation, error cases, and chained requests. Here is how it works under the hood.
01System Architecture & Grading Pipeline
DevForces operates on an asynchronous, event-driven pipeline. Submissions from the web editor are routed through an Nginx proxy to the API, which pushes a grading event to a Redis-backed BullMQ queue. A dedicated worker consumes this event, copies the boilerplate, and overlays the user's files to prepare the submission directory. It then spawns a sandboxed Node process, fires test cases against localhost, and writes the results to both Postgres and Redis.
02Infrastructure & Sandboxing
The Express API and grading worker run as pm2-managed processes on the host, while Postgres and Redis are containerized via Docker. The worker deliberately runs outside Docker because systemd-run requires direct cgroup access to enforce per-submission memory and CPU limits. Each grading job spawns an isolated Node process with MemoryMax=256MB and CPUQuota=50%, killed via SIGKILL after the challenge time limit expires. Port collisions between concurrent graders are avoided by reserving a free port before spawning and releasing it the moment the child process binds.
03Real-time Leaderboard with Dual Persistence
To handle high concurrency during contests without data loss, scores use a dual-write system. When a score delta is computed, the worker updates a Redis sorted set for sub-100ms O(log N) ranking retrieval and publishes to a Pub/Sub channel to emit live Socket.io updates to the web client. Simultaneously, it upserts the Leaderboard table in Postgres; if Redis ever restarts, the API seamlessly restores the live state from this Postgres backup.
04The Cumulative Unlock Mechanism
DevForces tests real-world backend engineering by merging your code as you progress. Challenge 4 isn't graded in isolation; it is graded against a complete snapshot that includes the base boilerplate, plus your passing code from Challenge 1, Challenge 2, and Challenge 3. This means if your authentication middleware from Challenge 3 is subtly broken, your protected routes in Challenge 4 will fail integration testing by design.
05Database Schema
DevForces runs on a relational Postgres schema — User, Contest, Challenge, ContestToChallengeMapping, Submission, and Leaderboard — designed for high concurrency, with Redis as a cache and message broker for real-time updates. ContestToChallengeMapping decouples challenges from contests for flexible configuration, while Leaderboard is tuned for fast upserts. The core design choice is in Submission: each attempt stores files (just the user's diff) alongside fullFiles (a snapshot merging boilerplate + all previously passed challenges + the current attempt). The grading worker always runs on fullFiles, ensuring a runnable codebase and fully reproducible re-grades.
