My system design for Leetcode
Writing a system design of leetcode has two interesting challenges. One is how do we run a website which has high availability so that users can run their code against test cases. The other is how do we display a user’s rank and score information.
Let me first declare some of the REST API endpoints that we could work with:
- GET /problems. This could also have optional params which can filter the problem set according to problem category.
- POST /solution. This would trigger the solution to run the code against the test cases. This would also establish a socket.io connection between the client and middleware which has the feature of telling the status of a particular test case in real time.
- GET /user-details. This would fetch the rank information of the user, along with submissions made, user name, etc.
Next, let’s design the databases that we will be using.
We will be needing a RDBMS database system that provides high availability. Most of the operations will be read operations on a day to day basis. Very rarely will a new problem need to be uploaded or a new change of statistics of user happen.
For this, I would design a master-slave setup of databases, that is I will keep a replica set of databases. I would keep a load balancer to balance traffic across the databases.
For the calculation of the user’s rank. We could have a script run everyday that ranks all the users and updates the rank of each user in the database.
The schemas for it would be:
Problems
name: varchar;
companies: varchar[];
description: varchar;
related_problems: varchar[];
topics: varchar[];
Finally, for the high level architecture, I would design it to have three layers: a frontend app, a middleware and a cluster of backends that run the actual test cases asynchronous and simultaneously.
The middleware would function almost as a microservice. It would serve the data of the various problems and user details.
The backend would as discussed be running the test cases. We would decouple this from the rest of the applications as this could be CPU and RAM heavy. We would be having a large number of instances of this behind a round robin load balancer. Typically, the input for this would be the solution code, the test case input and outputs and expected result would obviously be whether it succeeded or not with failure information if it succeeded.
