Distributed Consensus - Raft Leader Election | Systems Design Interview 0 to 1 with Ex-Google SWE

[@ololga]

In the past I didn't enjoy system design, but after trying it with Jordan my life changed and I started enjoying it. Thanks, Jordan for making all these videos!

[@jporritt]

I appreciate this length of video. Really convenient for getting complex topics.

[@msebrahim-007]

1 - (4:05) In general, how can a follower be behind the current term number? Does this imply the follow node went down and came back up at a time when there was a new term? 2 - (4:35) How is it possible that a follower is in a term number that is greater than or equal to the term number that is being proposed? Once again i'm thinking that this follower perhaps went down and is massively behind when it comes back online? As a follow up to this question, if this implies that there is already a leader for term 29, shouldn't the candidate stop its proposal altogether since there is already a leader for term 29?

[@jordanhasnolife5163]

1) Since raft only requires a majority of nodes to proceed with an operation, a follower that is offline and then comes back online can be behind. So yeah as you implied it comes back online during the new term. 2) Any node, including an outdated follower can propose a new leader election. In this case, one of the up to date followers basically needs to veto and start its own leader election. Imagine we have 5 nodes, and it is term 29. The leader goes down, and a follower proposes and creates term 30 becoming the new leader. That new leader then goes down, and the old leader comes back up. The old leader notices there is no current leader, and proposes an election on term 29, only to be veto'd by all of the other followers who were on term 30. The candidate will stop its proposal once a majority of nodes either say "no" or "there is already a leader" and respond to it.

[@reddy5095]

Suppose we have 5 nodes A B C D E, A is the current leader and it went down, B proposes and gets a yes from C and does not get a reply from other nodes and so B considers itself leader, At the same time D also proposes and gets a yes from E and does not get a reply from other nodes, Since both B and D got majority votes both will think they are the leader right?

[@jordanhasnolife5163]

Those aren't majorities. The "majority" size always applies to the original size of the cluster, which is 3 in this case

[@sahilkalamkar5332]

At 7:52, so essentially if there is a node which has more up to date logs then the leader being considered for election, those extra writes will be ignored if someone else is chosen as leader?

[@jordanhasnolife5163]

Yep, unless that write is in a majority of the nodes, in which case it isn't possible for there to be a new leader without the write

[@sahilkalamkar5332]

@@jordanhasnolife5163 so if the leader being elected receives a no from one of the nodes, but receives a yes from other nodes, will the election move ahead?

[@jordanhasnolife5163]

@@sahilkalamkar5332 As long as there are more "yes" votes than "no" votes, then the election should move along yeah

[@radosawmul8963]

@@jordanhasnolife5163 Hmm but what happens from the perspective of the user who actually inserted those rights? :O He has probably been presented with some "write successful" screen before and now his data is lost? Or is it like he haven't got confirmation that his write was successful, because quorum didn't agree on it yet. 👀

[@jordanhasnolife5163]

@@radosawmul8963 Yep you got it - you only get confirmation of your write once it gets to a quorum of nodes. If it's in a quorum of nodes, then an election to a leader without the write could not have passed, since that quorum will all vote no.

[@bokistotel]

@6:48 "If an older leader proposes a write with a lower epoch number than a current token we KNOW that it is an old leader". My question is why do we know for certain that is was an old Leader? Couldn't it be an old Follower that updated its epoch number? Or are we assuming that this is a single leader replication and the one who proposes a write by definition must be/was a leader ?

[@jordanhasnolife5163]

You're correct on the 2nd thing you said

[@dwivedys]

Pretty, pretty tough! Consensus is as tough in tech as it is in real life I guess….

[@yrfvnihfcvhjikfjn]

This dude is casually bragging about leaving his house. Smh not even a real shut in

[@jordanhasnolife5163]

Lol imagine going outside

[@sebuszqo3239]

hi, so what in case when we have 3 nodes and leader goes down? then election is 50:50? One node will say I am a candidate and if second one say "yes you are" everything is fine but what if the second node will say "no"?

[@jordanhasnolife5163]

Yep! It's only fault tolerant to an extent, it can never be perfectly fault tolerant!

[@PrabhuMarappan7]

At 2:51, you say that each node complains after random unit of time. But is that because each node has a different time to wait till the next heartbeat or is there? Or both are different?

[@jordanhasnolife5163]

Yeah exactly, each node gets configured with a slightly different time to start an election after thinking the leader is down

[@rahullingala7311]

How do the nodes know how much of it's log it should communicate with the other nodes? Won't the logs be too huge?

[@jordanhasnolife5163]

They go backwards from the start one entry at a time to catch them up

[@msebrahim-007]

@@jordanhasnolife5163 Having trouble understanding "go backwards from the start". If we assume a leader has the following writes in its log 89 88 87 86 And a followers log is on write 86, does this mean the leader starts at write 87 and goes to 89? Then the leader will send 87-89 to the follower?

[@jordanhasnolife5163]

@@msebrahim-007 It means they try to send 89, and the follower says wait I actually also need 88 and 87.