> how does it re-sync the current, up-to-date state to the new node it is a core feature of the protocol. > how does it make sure that when one of the nodes f

> how does it re-sync the current, up-to-date state to the new node it is a core feature of the protocol. > how does it make sure that when one of the nodes fails - that all of the clients do not overwhelm the rest of the system. for write access (proposals), in a typical implementation (defined below [1]), one failed nodes actually slightly speed up the system with the cost of reduced reliability. Consider a typical setup with 3 nodes, the leader normally replicate state to 2 followers, the replication cost get cut in half once your cluster loses one member. given that you can implement linearizable read by going through the write procedure, one can argue the above "speed up" can obviously be achieved on reads as well. [1] independent replication to followers, for N followers, the same entry will be serialised and sent N times by the leader. again - just talking about typical implementation and the described "speed up" comes with degraded reliability.