Labyrithm
A self-hosted competitive programming platform built to evaluate genuine algorithmic problem-solving skills in onsite university contests.
The origin
Labyrithm was created for Algothon, the competitive programming championship held as part of SLIIT Codefest.
Organizing an onsite algorithmic contest for dozens of university teams comes with unique operational headaches. Relying on public, cloud-hosted platforms introduces external points of failure: sudden internet hiccups on campus, unexpected rate limits, and zero visibility when submissions queue up.
At the same time, the rise of coding assistants meant that standard online contest formats no longer measured genuine understanding unless the evaluation environment was controlled. We needed an end-to-end competition system that could run reliably on a local campus network while keeping the playing field fair.
Eliminating message brokers
Most existing self-hosted online judges rely on a complex web of infrastructure: separate Redis instances for caching, RabbitMQ for task queues, and external worker processes. During high-concurrency bursts when every team submits code at the final buzzer, that multi-service stack is prone to race conditions, memory spikes, and dropped jobs.
I wanted Labyrithm to be operationally lean. Instead of introducing external message brokers, the backend uses PostgreSQL as both the transactional store and the distributed job queue.
Using PostgreSQL transactions with row-level locks (
SKIP LOCKED), judge workers atomically claim submissions directly from the database. If a worker node crashes mid-evaluation, the uncommitted transaction automatically releases the job back to the pool. This eliminated entire layers of operational complexity while guaranteeing zero dropped submissions.The sandboxing pipeline
Executing untrusted code submitted by dozens of competitors requires strict boundaries:
- Isolated sandbox: Code is compiled and run inside Linux
isolatesandboxes with dedicated cgroups, locked down memory limits, physical CPU affinity, and zero network access. - Multi-language grading: Supports C++, C, Python, Java, Node.js, and Rust with language-specific timeout multipliers.
- Real-time verdict streaming: Test case results are not held until the entire suite finishes. Using PostgreSQL notifications and Server-Sent Events, individual test verdicts stream live to the competitor's screen as each test finishes.
- Dynamic scoreboard: Scores calculate automatically based on problem point weights and submission timestamps, with a configurable scoreboard freeze during the final minutes to preserve suspense.
Honest evaluation without intrusive software
One of the hardest design decisions was handling proctoring. Many commercial assessment tools force participants to install invasive kernel-level drivers or closed spyware, which is unacceptable on personal student laptops.
To address this, I designed a split-client architecture using Tauri and Rust:
- Headless background agent: A lightweight desktop daemon runs in the system tray, monitoring workstation focus and tracking abnormal bulk-paste bursts.
- Local loopback attestation: The web portal verifies the daemon's presence over a signed local loopback connection before accepting official submissions.
- Decoupled lifecycle: Because the proctor daemon is decoupled from the contest web interface, an accidental browser tab closure or UI freeze never breaks the student's active proctoring session.
- Organizer oversight: Contest administrators can monitor live telemetry, pause or extend contest timers across all machines simultaneously, and grant manual exemptions whenever a team experiences hardware issues.