Bifalgorithm post

Let's design LeCode. At first, it sounds simple. A user opens a coding problem, writes some code, clicks Submit, and a few seconds later gets accepted, or maybe wrong answer. But that one button actually triggers a pretty interesting backend system. First, we need the problem itself. Each problem has a title, description, constraints, examples, and most importantly, test cases. Some test cases can be public, so the user can try them manually. But many need to stay hidden. Otherwise, people could just hardcode the answers. Now the user writes code, maybe Python, maybe Java. Maybe C++, maybe JavaScript. The backend cannot just execute that code directly on the main application server. That would be a terrible idea. Users are literally sending you arbitrary code. Someone could write an infinite loop, try to read system files, allocate all your memory, or intentionally crash the machine. So instead, every submission gets sent to an isolated execution environment. Think containers, sandboxes, or lightweight virtual machines. The important part is the user's code gets strict limits. Maybe two seconds of CPU time. Maybe 256 megabytes of memory, no unrestricted network access, and limited access to the file system. Now the code needs to be prepared. For Python, maybe we can execute it directly. For C++ or Java, we first need to compile it. If compilation fails, we immediately return compilation error. If it succeeds, we run the program against the hidden test cases. For each test case, we provide an input, capture the output, and compare it with the expected answer. If one result is wrong, wrong answer. If execution takes too long, time limit exceeded. If it uses too much memory, memory limit exceeded. If it crashes, runtime error. And if every test passes, accepted. But now imagine thousands of people submitting code at the same time. You cannot execute all of these submissions on one server. So we introduce a queue. When a user clicks submit, the API creates a submission record and pushes a job into a queue. Then a pool of judge workers picks up those jobs and executes them. If traffic increases, we add more workers. If traffic drops, we can scale them back down. This separates the normal Leacode application from the dangerous and expensive code execution workload. Now there's another important detail. Running every test case one after another can be slow. So for large problems, the judging system can parallelize some execution work across workers. But we still need deterministic results and strict resource accounting. And what about the leaderboard? You probably don't want to calculate rankings for millions of submissions every time somebody opens the page. So things like contest scores, accepted counts, and rankings can be pre-computed and cached. Same thing for problem lists. Popular pages can sit behind a cache instead of hammering the database. So if we simplify the architecture, Leacode is really two major systems. The normal web application handles users' problems, submissions, contests, and rankings, and the judge system handles untrusted code. The API accepts the submission. The queue buffers the workload. Isolated workers compile and execute the code. Test cases verify the result. And the database stores the final verdict. The hard part about building Leacode isn't displaying a code editor. It's safely running thousands of programs written by complete strangers without letting any of them destroy your infrastructure.

Let's design LeCode. At first, it sounds simple. A user opens a coding problem, writes some code, clicks Submit, and a few seconds later gets accepted, or mayb…