Unlock it once for 15 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
What it must do
Show problem pages fast, to many readers at once.
Accept a code submission instantly and run it later against the hidden tests in an isolated sandbox.
Let the user poll for the verdict (accepted, wrong answer, time limit).
Survive a contest start, when everyone loads problems and submits within the same minute.
Scale
1,500 requests a second on a normal day: 1,050 problem-page views, 375 result polls, 75 code submissions.
Each submission runs about 1 s of tests in a sandbox: about 75 sandboxes busy at once.
A contest starts: traffic jumps to 4× for 8 s, with 300 submissions a second.
Request types to route: problem (70%, read), result (25%, read), submit (5%, write). Budget: $5,000 a month.
Estimate first
Submissions judged a day (million)
Sandboxes busy at once on a normal day (1 s a run) (sandboxes)
Submissions waiting after an 8 s contest burst if the sandboxes judge 120 a second (submissions)
Monthly cloud cost of your design (USD)
The test cases
You start from an empty canvas. When you run the tests, each one simulates your design with its own traffic and failures:
Test
What it does
Passes when
Normal day
The normal day: the traffic in the brief, nothing broken.
Success ≥ 99.9%; p99 latency ≤ 150 ms (problem); p99 latency ≤ 300 ms (submit)
A contest starts
At 5 s a weekly contest opens: 4× traffic for 8 s, everyone loading problems, submitting and polling.
Success ≥ 99%; p99 latency ≤ 500 ms (submit)
Cache flushed
At 5 s the cache on the request path is emptied, as after a restart or a bad deploy.
Success ≥ 99%; p99 latency ≤ 500 ms (problem)
A server dies
At 4 s one server of the first app service on the request path dies for 10 s.
Success ≥ 99%
Budget: $5,000/month
The normal day's design must cost at most $5,000 a month.
Cost ≤ $5,000/month
Must include
A cache for problem pages. Problem pages are read thousands of times and change rarely: serve them from memory.
A submission queue. Submissions arrive in bursts; a queue accepts them at once and lets the sandboxes work through them at their own pace.
Sandboxed runners. Untrusted code must run isolated, with CPU and time limits, never on the web servers.