I am a software engineer at Amazon, and your videos have helped me a lot. I was recently able to get senior and principal level offers from Oracle, Microsoft, and a few others. Thanks again. Appreciate it.
@jordanhasnolife51636 ай бұрын
Holy moly that's awesome!! Congrats on your offers!!
@ganesansanthanam-58965 ай бұрын
Hey, can we connect on LinkedIn?
@pratyushkumarsingh61616 ай бұрын
Once you read Designing Data-Intensive Applications all the videos becomes a great source to revisions. Great quality videos, keep up the good work!!!!
@TheSdl796 ай бұрын
The intro is hilarious😂p.s. congrats on the 30k milestone!
@adrian333dev6 ай бұрын
Thanks for the content! Preparing for an upcoming Mid level role, hopefully your videos will help me
@jordanhasnolife51636 ай бұрын
Good luck!
@Rambo0524g18 күн бұрын
Hi Jordan - Another great video - For Single Leader Synchronous Repliction - If the Replica dies, wouldn;t there be some zk to tell leader how many acks. to wait instead of leader waiting for the response from dead replica ? if this make sense..is there any other reason why sync replication in Single Leader is not good besides latency ? it seems to me it is fault tolerant like distributed consensus
@jordanhasnolife516317 күн бұрын
Well then you need zookeeper, which isn't even single leader lol. But if the one replica that we're synchronously replicating to dies, presumably we'd stop writing, because the whole point of synchronous replication is that we're 100% sure that all committed data is replicated.
@SohailKhan-gu2du6 ай бұрын
Hey , I love the way you teach . Can you also do this concepts in hands-on project in spring boot or something , so that we can improve our coding and also learn how to test such scenario in real Life
@jordanhasnolife51636 ай бұрын
This is something I've thought about, but realistically would take me a very long time to do haha. In my current state, it's unlikely I can, but maybe if I have some significant life changes
@rishabhsaxena80966 ай бұрын
Hey Jordan , Could you please create a video on stock exchange system design, that would majorly focus on the users getting a notification on the stocks they have subscribed if the stock values go up or down based on some parameters in real time. Thanks
@jordanhasnolife51636 ай бұрын
Will do eventually!
@chaitanyatanwar81517 күн бұрын
Thank you!
@ananth115 ай бұрын
Well when you feel you are better you don’t have to prove it to anyone, just relax and see ahead and I am sure you will find a much better girl than her !!
@jordanhasnolife51635 ай бұрын
Oh she's fine this was just a joke lol
@traveling_cruiser4 ай бұрын
Awesome video.. one question.. what is the leader/follower nodes here: application server/ redis cache/ database?
@jordanhasnolife51634 ай бұрын
Probably just a normal SQL db
@oren231986 ай бұрын
hi jordan thanks for those vidoes very helpful, but something it's clear for me how does s3 handles the fencing tokens? doesnt the appliation requires another layer for solving this out?
@jordanhasnolife51636 ай бұрын
S3 is a bit of a bad example because we don't own s3. But imagine you own whatever data source you're sinking to, you can just build this into the logic there.
@hazardousharmonies6 ай бұрын
Excellent job Sir
@kevinburke39412 ай бұрын
I'm confused about something. You mentioned around 4:20 that client 1's lock will expire due to the garbage collection, but then around 5:00 you say that when client 1 comes back they "still have the lock." I thought it expired for them?
@jordanhasnolife51632 ай бұрын
Client 1 just *thinks* it has the lock. It doesn't actually.
@shobhitarya16375 ай бұрын
Nice Video but i have one query. In case of distributed consensus, how reads are done for lock ?. If it is read from replica which is not upto date, it can lead to a problem. I have also watched your raft videos, which gives me impression that distributed consensus provides lineraliziability but not strong consistency in reading.
@jordanhasnolife51635 ай бұрын
You read from the leader. This is slow, but it's still fault tolerant, because we have the ability to perform a fail over if the leader goes down.
@nguyentrunghieu62003 ай бұрын
I'm kinda curious about the fencing token, since the destination write (in your video it's S3) it has to know/store the value of used fencing token so far, is that possible? Since I think that we might have to communicate with many 3rd parties which we do not have the "right" to do that check. How can we resolve it?
@jordanhasnolife51633 ай бұрын
I'm not sure what you mean here. A fencing token is just a number that you can pass to an external service, as long as the external service allows it in their API. Then the external service will only accept writes in an increasing order of that number.
@nguyentrunghieu62003 ай бұрын
@@jordanhasnolife5163 " as long as the external service allows it in their API" - that's my point. I meant, we can't be sure that the external service we want to use will always support fencing token (or have similar thing), what should we do in that case?
@jordanhasnolife51633 ай бұрын
@@nguyentrunghieu6200 Use a different external service or add a stateful proxy in front of it
@stormShadow646 ай бұрын
You are doing awesome work
@ashutoshshukla62425 ай бұрын
How can anyone through the notes you have made during these videos? Is it present in any GitHub repository or somewhere else?
@jordanhasnolife51635 ай бұрын
See channel description
@theJeet86 ай бұрын
Your intros are always weirdly funny :) Question: in your final design, is the queue also written to followers? i.e. If Leader were to go down, would followers know that B is waiting for A? How would the websocket be restored by A?
@jordanhasnolife51636 ай бұрын
Yep, the queue is written to followers. If the leader goes down, the clients will notice it, and reach out to the other links of nodes in the zookeeper cluster to get the address of the new leader and connect there.
@visheshchanana56586 ай бұрын
In the Distributed Conses, we had 5 nodes(1 leader, 4 followers). When leader went down, we chose the follower that was up to date. What if as soon the follower was chosen as a leader, it went down. Now we have 2 nodes with old data and 1 with new. What happens in this case?
@jordanhasnolife51636 ай бұрын
The one with new data must become the leader. If it goes down, we can't proceed as we can no longer reach a a majority of nodes.
@NoName-lz6bc2 ай бұрын
Make irrelevant question but how will things work when there are multiple resources to contend for. Eg one s3 file second s3 file maybe a customers sms channel. ? How will distributed consesus work then
@jordanhasnolife51632 ай бұрын
You use a separate lock for the other file.
@NoName-lz6bc2 ай бұрын
@@jordanhasnolife5163 when the master node fails then backup node1 have latest version of lock 1 but node2 has latest version of lock2. Then who will be the leader?
@vipulspartacus77716 ай бұрын
Hi Jordan, really appreciate the content, is it possible for you to share your ipad notes. It is difficult to follow and revise your content without the notes and making the entire notes while following the video is time consuming. It would be really helpful if you could share your hand written notes from ipad (maybe it is not perfect but still a better reference than nothing) which we could keep as reference to follow your content. As we go through the video, we could add our own comments or notes on it to make it more clear. Please consider.
@jordanhasnolife51636 ай бұрын
Planning on doing this in bulk after finishing my current series, this will be in the next 1-3 months.
@Keira77L-t3b3 ай бұрын
In the linearization problem example, can't B do a read repair and only grabs the lock after the repair to mitigate it?
@jordanhasnolife51633 ай бұрын
Sure, but how does B know that this is state it's supposed to read repair?
@Keira77L-t3b3 ай бұрын
@@jordanhasnolife5163because B reads B:2 from one node, and B:1 from the other, so it knows to ‘fix’ the other node with B:2 (assuming quorum).
@jordanhasnolife51633 ай бұрын
@@Keira77L-t3b In this particular case yes, however there are unfortunately cases in leaderless replication where for example in N:3, R:2, W:2 with 3 clients writing that they can all achieve quorum and all 3 nodes achieve different values. See my most recent dynamo video.
@divijsharma56104 ай бұрын
Why this channel name man , you are giving life to so many. Rename the channel to Jordan gives life
@jordanhasnolife51634 ай бұрын
That's not the only thing I give
@fallencheeto47624 ай бұрын
Is linearizable similar to causal consistency?
@jordanhasnolife51634 ай бұрын
Causal consistency just implies that if a write B happened because a user first saw write A, we should never be able to read B without also having access to the A write Linearizable databases are causally consistent, but not all causally consistent databases are linearizable.
@fallencheeto47624 ай бұрын
@@jordanhasnolife5163 interesting, we learn something new everyday! Great video man
@michaelv25556 ай бұрын
No Flink and CDC used? Jordan, are you ok?
@jordanhasnolife51636 ай бұрын
No someone said my videos were too unrealistic for interviews on reddit and now I'm in a deep state of depression
@Ynno26 ай бұрын
@@jordanhasnolife5163 I think that's true, but I don't necessarily think it's bad. Your videos aren't really structured in an interview style. You go into a lot of depth in your designs. It would be unrealistic to draw the sometimes huge designs your show at the end of your videos in the space of an interview - especially somewhere like Meta where you realistically only have 35 minutes of design time, but it's beneficial to see everything as inspiration for how you might deep dive in different areas. In a real interview you may only deep dive into a couple of the areas you show.
@MallardDuck776 ай бұрын
LE'S GO KNICKS!
@jhonsen98424 ай бұрын
I rejected in System Design Round LoL I took it lightly and didn't prepare
@jordanhasnolife51634 ай бұрын
Welcome
@codr05146 ай бұрын
What editor are you using for drawing? Do you also use any pen based device?
@jordanhasnolife51636 ай бұрын
Apple pencil + oneNote
@codr05146 ай бұрын
@@jordanhasnolife5163 thanks for your response 🫡
@rafaelarantes48046 ай бұрын
The content is great, but I always come for the golden nugget in the description
@jordanhasnolife51636 ай бұрын
I churn out nuggets in the description and on the toilet
@RolopIsHere2 ай бұрын
I had to debate with myself if I left the video with 69 comments or if I added a comment to help your video with the algorithm...
@Algorithmswithsubham6 ай бұрын
congrats, whta introo
@helperclass87106 ай бұрын
Thanks for the great video. I need your help with one of my task. I will become your patreon if you help. In my current company I have received one task in which I have to execute queries in the order they were originally executed. I have a list of queries and their original start and end times. So to execute them again in the same order we need to build dependency graph. How we can build this dependency graph. Query 1: start time 1 end time 3 Query 2 start time 2 and end time 5 Query 3 start time 4 end time. Qry 2 can start after qry 1 has started. Query 3 can be started after 1 finished and 2 started
@helperclass87106 ай бұрын
My implementation is not efficient as I am checking for every query all the query started before it and storing the dependencies in list
@jordanhasnolife51636 ай бұрын
Doesn't really make much sense to me considering the start times and end times. But look up topological sorting. Make a graph of the dependency relationships, and run a topological sort. This will tell you when you can schedule a given task, at which point you can run a second job that looks at currently scheduled tasks and whether their start time has passed. I don't have a patreon, send it to charity.
@mcee3116 ай бұрын
what if you have a large amount of connections on the leader node? How do you deal with that situation?
@jordanhasnolife51636 ай бұрын
I'm assuming this is for many different locks, you basically have to partition them across many zookeeper clusters.
@潘雪松-f4g6 ай бұрын
@@jordanhasnolife5163 does that mean this leader + several followers just act like one zookeeper node. And for horizontal scale up we need more zookeeper nodes with sharding(and every node have their own leader and followers)?
@jordanhasnolife51636 ай бұрын
@@潘雪松-f4g You are correct
@sid45796 ай бұрын
What is the source of truth for all this?
@jordanhasnolife51636 ай бұрын
I'm not sure what you're asking - do you mean my sources?
@sid45796 ай бұрын
@@jordanhasnolife5163 Thanks for replying! I meant where did you learn about all this? Is there a comprehensive resource or is this just result of your years of experience in tech?
@jordanhasnolife51636 ай бұрын
@@sid4579 Well considering that I don't have many years of experience in tech, I'm going to say that I did not learn anything that way. I'm simply just aggregating any information that I can find across anywhere on the internet. If there was a comprehensive resource for it, I don't think I'd be making these videos in the first place, as I myself am attempting to be a comprehensive resource for it.
@Ynno26 ай бұрын
@@sid4579 Martin Kleppmann's book and KZbin videos cover a lot of this.