Loading…

Understanding the problem

Millions of people read problems, press Run to try their code on examples, and press Submit to be judged against hidden tests. Once a week a contest opens new problems to a hundred thousand people at once, with a live ranking. The happy path is a compile and a comparison. The hard parts are that the code is written by strangers, some of it hostile, that the tests must stay secret, and that the contest’s first minutes ask for tens of times the normal judging capacity.

The practice brief sets the scope below. Settle early how hostile to assume submissions are, what a user may see when they fail, and how the contest ranks people.

Functional requirements

CoreUsers browse problems and read statements, examples and editorials.
CoreUsers run their code on the examples or their own input, and submit it to be judged against the hidden tests, in one of five languages.
CoreUsers see each submission’s progress and verdict, and their past submissions.
CoreContests open new problems to registered users for a fixed window, with a live ranking.
Below the lineDiscussion forums and comments.Ordinary web features, unrelated to judging.
Below the lineHints and AI help while solving.A product layer on top of the platform.
Below the lineA live interview mode with a partner.Collaborative editing is a different problem.

Non-functional requirements

SecuritySubmitted code cannot reach the internet, the platform’s machines, other users’ data or the hidden tests.
DurabilityEvery submission the platform receives gets a verdict; none is lost.
LatencyRun results within 5 s at p95; verdicts within 30 s at p95, and within 90 s at a contest’s peak.
ConsistencyThe same code gets the same verdict, whenever it runs.
ConsistencyThe contest ranking is live within about 5 s and correct once the contest ends.
AvailabilityBrowsing and submitting are available 99.95% of the time.
Below the line

Scale

From the briefNumbers here are given in the practice brief.

ScaleAbout 2 million users a day and about 3,000 problems.
ScaleAbout 500,000 submissions and 1.5 million runs a day on a normal day.
ScaleA weekly contest of about 100,000 people, peaking at about 1,000 submissions a second in its first 10 minutes.
ScaleAbout 50 hidden tests per problem, 1 to 2 seconds per test; a typical accepted submission uses about 2 seconds of processor time.

Out of scope

Out of scopeProblem authoring tools.
Out of scopePayments and subscriptions.
Out of scopeMobile apps.

Check yourself

Why ask what a user may see when they fail a hidden test?
Show answerHide answer
It decides whether hidden tests can leak. Showing the failing input or the program’s output reveals the tests, so the answer shapes the whole judging path.

The numbers that shape the design

Illustrative exampleNumbers here are illustrative: round figures to reason with, not measurements.

Turn the brief’s givens into processor time, not requests: every submission runs many tests, and a contest arrives all at once.

Back of the envelope from the brief

Quantity	Value	What it means
A normal day	About 6 submissions a second	500,000 a day over 86,400 seconds.
Contest peak	About 2,000 busy cores	1,000 submissions a second at about 2 CPU-seconds each.
With runs	About 3,000 cores	Tens of times the normal need, for minutes.
Worst-case submission	About 100 CPU-seconds	49 tests just under 2 seconds, and the 50th fails.
Ranking reads	About 3,300 a second	100,000 people refreshing every 30 seconds.
Code stored	About 0.7 TB a year	500,000 a day at about 4 KB each.

Architecture diagramWhat the contest peak asks of the platform

Illustrative figures from the brief: judging is sized in processor time, and the ranking is read far more often than it changes.

Diagram as text

Components: Contest submissions (Client); Judging (Worker); Runs on examples (Client); More judging (Worker); Contestants refreshing (Client); Ranking (Cache). Connections: Contest submissions → Judging (about 2,000 cores); Runs on examples → More judging (about 1,000 cores); Contestants refreshing → Ranking (about 3,300 reads/s).

Read:Learn: Numbers and capacity estimation

Try it: The numbers that shape the designGuided practice · Coding practice platform, Practice and contests · Senior

Check yourself

Which number most shapes this design?
Show answerHide answer
The contest peak in cores: tens of times the normal need for a few minutes. New machines take minutes to be ready, so capacity must exist before the start.

Core entities

Problems and their tests are versioned, so every verdict can say exactly what judged it. Judging is recorded as append-only attempts, so a rejudge adds a result rather than overwriting one. Large files live in object storage by key.

The records that matter

Entity	Key fields	Why it exists
Problem version	`problem_id`, `version`, statement, limits per language, judge mode, `test_set_version`	A fix creates a new version rather than an edit in place.
Submission	`submission_id`, user, problem version, language, code key, contest, status, current verdict	Indexed by user and time for history, and by contest and problem.
Judge attempt	`attempt_id`, submission, test version, runtime image digest, verdict, time, memory	Append-only, so any verdict can be reproduced and explained.
Test result	attempt, test number, verdict, time, memory	Per-test detail, kept for a while.
Contest result	contest, user, problem, solved at, wrong tries before	One row per person and problem; the ranking comes from it.

Architecture diagramThe records, and what points at what

Diagram as text

Components: Problems and versions (SQL DB); Test files by version (Object store); Submissions (SQL DB); Judge attempts (SQL DB); Contest results (SQL DB). Connections: Problems and versions → Test files by version (test set version); Submissions → Problems and versions (problem version); Submissions → Judge attempts (append-only); Judge attempts → Test files by version (judged with); Submissions → Contest results (solved, wrong tries).

Read:Learn: Data model design Learn: Storage choice justification

Try it: Problems, tests, submissions and verdictsGuided practice · Coding practice platform, Practice and contests · Senior

Keep reading+1 min

How long to keep what

Keep code, verdicts, image digests and judging attempts for as long as appeals and rejudges can happen; after that, move old code to cheaper storage and trim per-test rows. The submissions table grows by half a million rows a day, so split it by time and keep the indexes a user’s history and a contest’s results need.

Check yourself

A test is fixed a week after a contest. What must the records hold?
Show answerHide answer

The API

Submit returns at once with an id; the page follows the submission until its verdict arrives, and long lists page by cursor.

A compact contract

Call	Request	Response	Errors
`POST /v1/submissions`	problem, language, code, run or submit, contest; an `Idempotency-Key` per click	`202` with the submission id; a repeat returns the same id	`400`; `429` only for an account over its limits
`GET /v1/submissions/{id}`	None	Status, then verdict, time, memory and failing test number	`404`
`GET /v1/submissions/{id}/events`	None	Server-sent events: running, then the verdict	Falls back to polling
`GET /v1/users/me/submissions`	problem, cursor	Newest first, one page	None
`GET /v1/contests/{id}/ranking`	cursor, or around=me	A page of ranks	None

Read:Learn: API contract design Learn: Idempotency and retries

Try it: What the site and the judges callGuided practice · Coding practice platform, Practice and contests · Senior

Keep reading+1 min

Runs versus submits

Runs outnumber submits three to one in the brief and do not touch the ranking, so treat them as a separate, cheaper lane: fewer tests, shorter limits, output shown for examples and the user’s own input, and first in line to slow down when the platform is busy. A submit carries the contest and the penalty, so it gets the durable path and the stronger guarantees.

Check yourself

The reply to a submit is lost and the page retries. What stops a second penalty?
Show answerHide answer

High-level design

Two flows from the brief carry the design: a user submits a Python solution to problem 42, and the user sees the verdict.

Submitting: saved first, then handed on

The API stores the code in object storage, then writes the submission row and an outbox row in one transaction, and replies 202 with the id. A relay publishes the job to a durable judge queue, so a crash between saving and handing off cannot strand the submission, as in the transactional outbox (opens in a new tab) pattern.

The page posts the code with a key it generated for this click.
The API stores the code, then the submission row and an outbox row in one transaction.
It replies 202 with the submission id, and the user sees “submitted”.
A relay reads the outbox and publishes the job to the durable judge queue.

Architecture diagramSubmitting: saved first, then handed on

The row and its job commit together, so a crash between saving and handing off cannot strand a submission.

Diagram as text

Components: Submission row and outbox (SQL DB); Outbox relay (Worker); Browser (Client); Submissions API (API gateway); Judge queue (Queue); Judge workers (Worker); Code by key (Object store). Connections: Browser → Submissions API (POST, client key); Submissions API → Submission row and outbox (one transaction); Submissions API → Code by key (store the code); Outbox relay → Submission row and outbox (read the outbox); Outbox relay → Judge queue (publish the job); Judge workers → Judge queue (pull).

Read:Learn: Long-running tasks Learn: Producer-consumer / work queue

Try it: A submission, end to endGuided practice · Coding practice platform, Practice and contests · Senior

Check yourself

Why not write the row, then put the job on the queue, in two separate steps?
Show answerHide answer
A crash between them leaves a saved submission with no job, waiting for ever. Writing the job in the same transaction closes that gap.

Judging and telling the page

A judge worker takes the job, compiles and runs the code on each test in a fresh sandbox, and writes the verdict once for that judging attempt before acknowledging the job. If the worker dies first, the job is delivered again. The page listens on a server-sent events stream and falls back to polling every couple of seconds.

Architecture diagramJudging and telling the page

Design LeetCode

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

The numbers that shape the design

Core entities

How long to keep what

The API

Runs versus submits

High-level design

Submitting: saved first, then handed on

Judging and telling the page

Sign in with Google to read the rest

Practise this

The answer in two minutes

Also asked as

What interviewers look for

The decisions that matter

01Understanding the problem

Functional requirements

Non-functional requirements

Scale

Out of scope

02The numbers that shape the design

03Core entities

How long to keep what

04The API

Runs versus submits

05High-level design

Submitting: saved first, then handed on

Judging and telling the page

Sign in with Google to read the rest

12Practise this

Understanding the problem

The numbers that shape the design

Core entities

The API

High-level design

Practise this