Google SWE teaches systems design | EP1: Database Design 

I love this video for two reason 1. Dry humor 2. Dry humor, great content, loved the sarcasm and the knowledge. Thanks for putting this up

Have watched a few of your videos, definitely subbed and going to work through them. I really appreciate the point you made that other videos don’t dive deep enough into the inner workings of a system. “For the backend we will use a MySQL database and a Redis cache…” and they stop there lol. This channel is just what a lot of people are looking for, please keep it up the videos are appreciated 👍

Wow, this is such a great summary of some chapters of the book you recommended at the end. Love your style of presenting, clear, concise, with a funny twist! Thanks for your work!

mannnnnnn I wish I found your profile soooner, I would have LOVED to learn from your content during my dbms class last semester.... anyways, 5 minutes in and it is great so far, thank you for making this level of learning freely available. Godspeed and have a good day sir, keep up the good work

This channel is a goodmine, thanks for the amazing work!

I like your introduction and the attitude to dive deep!

Excellent content! Learned a ton thanks for making this

This is a truly epic video and I am glad I found your channel

Great video! Will be watching the rest!

Another great video. Appreciate the humor as well. Thank you for this content

Thank you for these videos. Great work.

This is a great resource! Learnt a ton! Btw I like the sound of your voice too! 🤩

Just started with your playlist great explanation

Best systems design content out there

B- Tree is stored in disk but is usually kept in memory for faster access. In case the B- Tree is too big to fit in memory, we keep root and internal nodes in memory. So, write operations are performed in memory and persisted in data file which is similar to buffer flush in SSTables and LSM tree. In the video it is mentioned that we perform write operation on disk. Please correct me if I am wrong.

Great video, really liked it and can't wait to binge the rest of your videos. I had a question about where these different index data structures are stored. I know that hash indexes and memtables are stored in-memorty, but SS Tables and B Trees are stored on disk? IS that correct?

You are legend! Doing great job

Great quality content

Great video, keep it up

Would you please do similar in depth videos for Algo and DS as well. Your teaching style is unique and world will benefit from it..

Amazing series brother

Awesome content !! please add more info videos on purely data encoding and decoding, loads of proto buff magic is needed to be well understood, but rarely info is added

Great content 😃

great work

cool, thank you!

This is clutch af my guy. I was literally just thinking of starting a channel like this bc no content on youtube actually talks about how to build real world systems and its uber frustrating. Wild that the best stuff so far is someone who’s incoming/just joined. New engineer myself and system design is my jam. Keep up the great work and hope you’re enjoying google 😎

Great content, has a great balance between depth and breadth of system design concepts. Btw what is your Linkedin?

I struck GOLD. Thank you Jordan for having no life.

Hello Jordan, would you (or anyone) map these structures (SSTables, LSM, BTrees, Hash) to actual DB technologies? Cassandra, Mongo, Postgres etc., Or was this explained in other episodes?

Hey @Jordan, quick question .. all these indexes .. such as LSM Tree or BTree are still storing the reference to the actual data right ? The actual data is still being stored somewhere on the disk .. maybe on a append only log ? can data storage pattern affect the indexing strategy ?

Hey Jordan, I truly appreciate your video! I find it's kinda difficult to fully understand the part of having a Flink behind Kafka(have no experience about Flink or Kafka, so no deep understanding actually). Sounds like Flink is something like cache&data processing & DDB writer.. I think Kafka can handle replay as well. Could you help to explain why we truly need Flink here, or what will be the issue if we drop it(can Kafka take its responsibility)? (I think we need a strong reason that roots from requirement to use a certain tool after another when speaking to the interviewer) Thanks!

I hope you won't stop making video's

Heyy Jordan, I have a doubt around 4:06 timestamp(during the append log in implementation). I hope when we are appending the entry we are auto incrementing the id as well right?? In the video id wasn't shown as 5, if my understanding is correct it should be 5 right? Also, it seems like append log implementation is nothing but treating update operation as well as add operation both as same. Anyway, thanks for the great content mann. Enjoyed the video!!

I just watched like 10 times, also took some notes.

So I get how 2 SSTables can be merged in O(n) time. But what happens when you have a memtable that's too big, and now becomes an SSTable file that has duplicate keys? If we have 'n' SSTables already and have to add a new SSTable, then for each key in the new table, do we have to check every key of the previous 'n' files in order to come up with compacted SSTables?

What is the source of all the initial content on understanding of systems? Asking to go through that if there is some gap in understanding

will there be multiple SS tables even after compaction process? Are we trying to move towards single compacted SS table ?

Would you mind sharing the slides as it will be good for quick revision during interview times?

11:26 Are SSTable entries a fixed size? Because if they're a variable size, I don't think you can do a binary search. Would have to linearly scan.

If one db uses LSM + SSTables and another db uses B+ trees, but both respond to the client immediately after writing to the Write Ahead Log (and periodically update the disk data structures asynchronously), would write performance be equal? Db examples could be Cassandra and Postgres.

When merging two SSTables, surely they aren't both wholly loaded into memory and then a "merge-sort-style" merge is done of the two sorted lists, right? Because weren't they written to disk because they were too large for in-memory? So are pieces of them loaded into memory and merged in-memory, then written to disk in some iterative sliding window-y fashion over the pair of SSTables? And re: the "good for range queries" @ 12:25 -- It's possible that SST #3 (the newest one) has "Bad", "Bid", but SST#1 (oldest one) has "Bed", right? So while there's good locality within a single SST, doesn't a range query still require traversal of all SSTables on disk?

GOAT

Hash indexes should be fast if you're accessing them from an SSD, right? When you say they're slow on disk, does that only apply to HDD?

7:10 - 7:20 You gotta love this guy

If hashMap on hard drive is not scalable, is the same true for SSDs?

What are your reference sources? Alex Xu books?

hi, would you mind sharing the resources that you followed for low-level design?

Would it be possible to share the presentation slides??

Hi Jordan, Can you also share the ppt you used in this video

Starting today

The penis references are pretty cringe but the content is solid and well paced. Thanks!

I think I found gold~

big fan from China. please speak slower, I have problem in listening😀

What about if we have fixed schema and dataset is large and usecase is write heavy. We will tend to move towards RDBMS but as database engine used is Btree, how will it support Write heavy ops. What will be your call for the database design ?