Online judge (LeetCode)

01 · CONTEXT

An online judge at modest scale

The classic exercise is designing a platform like LeetCode, which helps engineers prepare for coding interviews and hosts periodic coding contests. The user sees the list of problems, opens a problem and writes the solution in several languages, submits the code and gets immediate feedback, and follows a live leaderboard during the contests.

The non-functional requirements shape the design: prioritize availability over consistency, guarantee isolation and security when running user code, return the submission result within five seconds, and scale to contests with one hundred thousand users.

According to Hello Interview's analysis, the real platform has a few hundred thousand users and about four thousand problems. Compared with most design exercises, it is a small-scale system, and that should weigh on the choices.

02 · MODEL AND API

Entities, endpoints, and a simple architecture

Three entities are enough. The problem stores the statement, the test cases, and the expected output; the submission stores the submitted code and the result of running it against the test cases; and the leaderboard stores the contest rankings.

The API follows the requirements one by one: a paginated list of problems, reading a problem with the starter code in the requested language, submitting a solution, and a paginated read of a contest's leaderboard.

For a small system, the analysis argues for a simple client-server architecture, even monolithic, because the cost of managing several services is not worth it. To store the problems, it chooses a NoSQL database like DynamoDB, since there are no complex queries and the test cases can be nested as a subdocument of the problem.

03 · EXECUTION

Where to run untrusted code

Running the submission is the point where the case gets interesting. The naive option, running the code inside the API server, is described as an enormous security risk. In addition, the code runs in the same process as the server: if it hangs, it takes the server down with it.

The analysis chooses containers, one for each supported language and reused across several submissions instead of creating a virtual machine per submission. It prefers them over a serverless function because it does not expect great variation in submission volume and wants to avoid cold-start latency.

1. The client sends the code and the problem identifier to the API server, which forwards them to the container of the chosen language.

2. The executor manages the language container, which runs the code in an isolated environment.

3. The executor triggers the container synchronously, waits for it to finish, and reads the output; the container itself makes no outbound calls.

4. The API server writes the submission result to the database and returns it to the client.

04 · SANDBOX

Hardening the container

Containers share the host kernel, so configuration determines security. The analysis lists additional measures, summarized below.

05 · SCALE

Submission spikes: queue and containers

The analysis's math starts from a peak of ten thousand submissions, each running about a hundred test cases, with a conservative assumption of one hundred milliseconds per case. That gives one million test cases, or one hundred thousand seconds of execution, and about 1,667 cores to finish within a minute. The source itself notes that in practice most cases finish in 10 to 50 ms.

Scaling vertically does not solve it: the largest AWS instance types reach a few hundred vCPUs, and a large, expensive machine would sit idle most of the time.

The solution is to scaling horizontally the containers for each language, with auto scaling groups adjusting the number of instances to demand. The only considerable risk is overprovisioning, which the source treats as manageable, since the cloud makes it easy to scale capacity up and down.

The analysis also proposes a managed fila between the API server and the containers: the API enqueues the submission and the containers pull items as they become available. Execution can take several seconds because the code runs against hundreds of test cases, which fits the long-running task pattern, in which the API immediately returns a job identifier and background workers do the slow work.

1. The client sends the code to the API server, which puts the submission on the queue instead of running it right away.

2. The executors pull submissions from the queue as they become available. The queue helps manage load and allows retries if a container fails.

3. When the executor gets the result, it notifies the application server.

4. The server updates the database and the cache at the same time.

5. Since the queue made the system asynchronous, the client polls for the result at intervals, every second in the source's proposal; the endpoint fetches the submission from the database.

Some candidates propose a persistent connection, such as WebSockets, to avoid polling. The source says it would work, but adds complexity and is not needed with polling every second.

06 · RANKING

Live ranking without taking down the database

The source defines the contest as ninety minutes long with up to one hundred thousand users. Scoring is the number of problems solved, and in case of a tie, the time to complete all ten problems counts.

The naive version queries the contest's submissions, groups by user, and sorts by the number of distinct problems solved, and the client repeats the request every few seconds. The analysis itself warns that this puts significant load on the database.

In Redis, the ranking lives in a sorted set with one key per contest: the value is the user identifier and the score is the total or the solve time. When a submission is processed, the set is updated with ZADD, and the top is read with ZRANGE in reverse order, with scores.

1. The client requests the contest ranking and repeats the request every five seconds.

2. The server reads the top directly from the in-memory sorted set, with no expensive database queries.

3. When a submission is processed, the database and the sorted set are updated.

The client receives the first pages of the top and fetches the following ones as it scrolls. The analysis prefers polling over WebSockets, which would be overkill for the modest number of users and the acceptable delay, and even suggests varying the interval, polling more often near the end of the contest.

07 · TEST CASES

One test suite for any language

Writing test cases per problem and per language would be a maintenance nightmare. The solution is to write a single set per problem, runnable in any language, with a standard serialization format and a test harness per language that deserializes the input, passes it to the user's code, and compares it with the expected output.

For a binary tree, for example, the analysis serializes the input into an array via level-order (BFS) traversal, and each language needs a harness able to rebuild it before calling the user's solution.

08 · WRAP-UP

Simplicity with a path to grow

The source describes a very simple system as the ideal, without over-engineering, but with a clear path to scale if needed. At the senior level, it expects you to discuss the pros and cons of container, virtual machine, and serverless function and justify the choice, and to move beyond drawing boxes and explain how to actually run the test cases.