Coding-Arena: The LeetCode Clone That Behaves Like a Distributed System

Most coding playgrounds stop at the editor. Coding-Arena goes further: it turns browser code into a submission lifecycle, with sandboxed execution, hidden evaluation, and a result record that behaves like a real judge. That shift changes the whole product. It stops being a toy and starts looking like infrastructure.

A coding site that never executes your code directly

The first thing worth noticing is what does not happen. User code is not run with a local eval path or a fragile child process shortcut. It is packaged up, sent to Judge0, and evaluated in a sandbox designed for untrusted submissions.

That matters because the repo splits intent cleanly. The Run path uses visible test cases so users can sanity-check their solution. The Submit path uses hidden test cases so the judge can grade the real answer without leaking the rubric. In other words, the UI looks simple because the architecture is doing the hard work.

The design is less about convenience than trust. If a solution hangs, times out, or tries something unsafe, the backend stays insulated. If a user submits multiple test cases, the server can wait on Judge0 without becoming the execution engine itself. That is the difference between a classroom demo and a system that can survive real traffic.

Why the judge flow matters more than the UI

The execution path in the backend is straightforward in concept and disciplined in practice. The submission controller fetches the relevant problem document from MongoDB, builds a batch request for Judge0, and then waits for all tokens to resolve. The polling loop is the unsung part of the architecture. It turns an external sandbox into a dependable asynchronous workflow.

This also explains the data model. Problems store starter code, visible test cases, and hidden test cases together. Submissions store runtime, memory, and status. That separation gives the platform a clean audit trail: what the user saw, what the judge saw, and what the judge concluded.

The AI tutor is constrained on purpose

Coding-Arena does not use AI as a generic chat window pasted onto a problem page. The tutor is shaped into a sequence. The prompt injects the problem title, description, and starter code, then asks Gemini to respond in stages: hints first, code review next, and only then an optimal solution if the user still needs it.

That restraint is the point. A tutoring assistant that blurts out the answer is useful in the wrong way. A tutoring assistant that can slow down, explain, and escalate only when needed is closer to a real mentor. The repo’s prompt engineering reads like a product decision, not a novelty.

This repo treats content creation like a production workflow

The admin side is where the project starts to look serious. New problems are not just saved. They are validated against a reference solution before they land in the database. That means the content pipeline has a built-in quality gate, which is exactly the kind of safeguard that many clone projects never add.

This is the kind of backend discipline that pays off later. A platform for practice problems is only as good as its problem quality. If bad content can enter easily, everything downstream becomes noise.

Express, Redis, and MongoDB, but made edge-friendly

The deployment story is more interesting than you would expect from a coding practice repo. The backend is a conventional Express app, but it is wrapped to work in Cloudflare Workers. That means the code has to respect a fetch-driven environment instead of assuming a long-lived Node process.

// Cloudflare Workers bridge
import { httpServerHandler } from 'worktop';
import app from './app.js';

export default {
  async fetch(request, env, ctx) {
    await ensureConnections(env);
    return httpServerHandler(app)(request, env, ctx);
  }
};

// Lazy Redis proxy pattern
const redisClient = new Proxy({}, {
  get(_target, prop) {
    return getRedisClient()[prop];
  }
});

That lazy connection pattern is the tell. Instead of assuming global process state, the repo defers initialization until the request path actually needs it. That is the sort of small architectural compromise that makes a traditional stack feel edge-compatible without rewriting the whole backend.

What Coding-Arena is really competing against

The right comparison is not with a polished consumer product. It is with the average online judge clone that can edit code, run code, and stop there. Coding-Arena has more moving parts because it is trying to model the real constraints of a production judge: isolation, grading separation, tutor behavior, admin validation, and deployment plumbing.

That is why the repo feels durable. It is not chasing novelty in the editor. It is building the boring but essential machinery around the editor, and that is where real products usually win.

Why this architecture feels more durable than most clones

Coding-Arena is interesting because it treats a coding practice site like a production system. It respects the fact that untrusted code needs isolation, submissions need asynchronous handling, problems need validation, and the deployment target can shape the architecture as much as the feature list. Those are not cosmetic choices. They are the difference between a repo that demos well and one that could grow into a platform.