Loading...
Host competitions
have a real time leaderboard for competitions
competitions are made up of three questions
be able to evaluate and run code
securely execute the code
clean the code
prevent cheating
10000 DAU
2000 users during a contest
maybe 100 RPS max
Leaderboard
GET /leaderboard (leaderboard_id)
POST solution (competition_id,problem_id, language, code) (user and timestamp handled in session/headers)
GET competition(competition_id)
GET problem(problem_id)
Users{
id: integer
email: varchar
}
Submissions{
id: integer
user_id: integer
time: float (milliseconds runtime)
code:varchar
language:enum[ languages ]
competition_id:integer
}
Competitions{
id: integer
problems: problem_ids[]
date_start:timestamp
date_end: timestamp
leaderboard:list[user_ids] (only after a completed competition
}
Problems{
id: integer
problem_text: varchar
code_stubs:json{language:varchar,stub:varchar}
test_cases:json{language:varchar,stub:varchar}
}
Our client makes requests through an api gateway which handles auth and input cleaning
our server returns most data models from the database, but the leaderboard is served by the in memory db (sorted redis cache).
requests to run code are sent to worker nodes running executors in docker containers
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
The worker nodes run docker containers which have code runners to execute the code. they record the start and end time of the code run to rank for speed. Our server records the time that code was submitted so we can have the first run recorded.
use an in memory db to maintain and update our leaderboard, sorted redis cache
workers nodes can be overwhelmed/expensive, api gateway should enforce rate limiting and throttling.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?