System Design Interview: Design LeetCode w/ a Google Engineer

[@Hufsa]

this is so well detailed, I didn't expect so great material in less than 20 minutes, impressing

[@SystemDesignSchool]

Thanks, glad you liked it!

[@michael_pio]

The quality of your content is Great , keep the good work up!

[@amithgangarapu]

The video and your explanation is just perfect! I hope your channel grows.

[@Bhaavgeete-ij2zs]

Wow.......Simply amazing. The quality of content surely deserves a Million Followers. Keep going this way, eager to learn more from you.

[@inventorokoth]

keep going man. really helpful what you're doing

[@TechieTech-gx2kd]

💡Let's stop obsessing over back-of-envelope calculations! Most interviews are already focused on high-scale systems (100k+ users), so why waste time calculating what we already know? Instead, let's dive into High Level Design, Deep Dives and have meaningful discussions about architecture choices at different scales. Compare solutions for both low and high traffic - that's where the real learning happens! Simply throwing around big numbers and tech buzzwords to sound smart? That's a rookie move. What matters is understanding WHY you choose certain solutions and HOW they impact your system as it scales. When you finished your section of calculations, tell me did you made any changes in your design based on these calculations if not then this is simply waste of time during interviews.

[@SystemDesignSchool]

I completely agree-focusing too much on back-of-the-envelope calculations can be a time drain, and the main emphasis of interviews should be on design. That said, having a rough idea of numbers can be valuable for informed decision-making. Designing for a small site is vastly different from designing for a platform at the scale of social media. For example, if you mention that QPS s high, introducing a queue as a buffer becomes essential. On the other hand, if user traffic is minimal, consolidating everything on a single server might be more efficient. I think it's important to realize the difference otherwise every design interview would just be high scalability buzzwords. I remember I had one interviewer asking me how to store 1M records. He wanted you to realize 1M is very little for a DB and you don't need all the high-scalability stuff. In practical scenarios, like designing a LeetCode-style teaching platform, running Docker on the web server could be sufficient for a smaller audience. However, for a large-scale competitive programming site handling millions of users, you would need to implement a buffer with queues and ensure redundancy is properly set up. While you can assume high or low traffic for simplicity in discussions, real-world software design always requires some level of calculation to make sound decisions so I don't think it's a complete waste of time. It's just the current study material out there focus too much on this. This is our first video so we want to tailor to audience who are looking for these things. Check out our other design videos where we talk less moving away from that. Also here's a resource that maps out how design choices shift based on QPS: systemdesignschool.io/fundamentals/qps

[@christywang4012]

if a submission requires 20 test cases to run, each of them requires 1s, then it requires to 20s to run? If we distribute it to different servers, then we need to run all of them then aggregate the results? I thought one failure would prevent remaining test cases to run.

[@SystemDesignSchool]

The implementation depends on the requirement of the platform. For example, LeetCode's implementation is one failure would prevent remaining test cases to run like you said. HackerRank and AlgoMonster actually run all the test cases even if some of them fail.

[@elitegamer8008]

Ohh nice video all the best for future Endeavours and bring more system design videos like this

[@SystemDesignSchool]

Yes, we will! Thank you for being our first comment!

[@shivanshbhat1056]

This is really helpful. Thanks !

[@lestrange-du-nil]

The document says 1KB for solution of each question, but you calculated it as 100KB per submission, is this a typo or am i missing something?

[@SystemDesignSchool]

1KB is the source code users submit, which is a bit low for verbose languages. I think 10KB is more appropriate. Thanks for the comment. We'll update the document.

[@arshdeepkumar]

using docker will still leak your code, message queue and db keys that you still will need to subscribe to queue and save results to DB maybe a way to disable file access and network for user programs

[@SystemDesignSchool]

user code runs in docker container has separate filesystem namespace and cannot access other processes

[@arshdeepkumar]

I mean in the docket container you'll have source code ? For polling and executing code ?

[@yosifsalim-nz3mp]

what did you use for documenting the API ?

[@SystemDesignSchool]

I used the tool here to document it and have AI grade it: systemdesignschool.io/problems/leetcode

[@XxRazcxX]

On 4:37 u said 556 Read QPS and 5.56 write QPS. Then on 5:47 you say 556 Write QPS and 5.56 Read QPS.

[@XxRazcxX]

I personally think its 556 WRITE QPS since submission are saved.

[@SystemDesignSchool]

Oh oops, it should be read 556 since the assumption is read:write 100:1 (we requests info from the server a lot more than we submit solutions)