Design Leetcode

Design Leetcode

Functional Requirements

1. Users can view a list of problems
2. Users view the detailed problem and code solutions
3. Users are able sumbit their code according to different language
   and get the answer.
4. Users are able to have the leaderboard support

Non Functional Requirements

1. availability > consistency
2. isolation in running the code
3. return the submission result fast maybe in 5s
4. the system should scale to support competitions with 100,000 users.

Core Entities

1. Problem
2. Solution
3. Leaderboard

API Design

看前100题
GET /problems?page={}&limit={} -> return Problems list

看第几题
GET /problems/:id -> return Problems

看solution
GET /problem/:id/solution -> return Solution

递交submission

POST /problem/:id/submit ->
{
code,
language
}
得到leaderboard

GET /leaderboard/:competitionId?page={}&limit =100

High level design

Note in current design for querying a leaderboard we just simply use dynamoDB.
we need to have the partition key be the competitionId. Then you’d pull all items into memory and group and sort.
If you want the system to be pretty live, we need to have query the db every 5 seconds. This approach is bad. We will discuss in the future design.

Dive Deep

1. isolation& security in running the code: CPU and Memory Bounds, Explicit timeout, read-only filesystem, No System Calls (Seccomp)
2. In order to query database quick, we need to use redis with sorted set. 我们可以每次用户提交一个submission，redis和dynamoDB同时更新，
3. 我们需要scale up, 超过100,000 users的时候，我们可以添加一个SQS+ worker，当用户提交一个结果的时候，我会放进SQS中，当某个container有结果的时候我notify server，并且有个worker写入db & cache里面
   当用户需要结果的时候需要1s的一个polling直到server接受请求
   好处是能够确保我每一条request都能够很好的处理
   但是坏处是添加了很多复杂度
4. 我们如何实现test case？那肯定是用serialize & deserialize.

Final High level design