Why Raft Can’t Safely Commit Old-Term Entries

Raft is a consensus algorithm that allows a group of servers to agree on the order of a sequence of commands. The objective of this article is not to re-explain RAFT, as this work has already been done in several other places, and the RAFT paper gives enough details to implement it. Instead, my focus will be on two problems that I faced when I voluntarily studied the open distributed systems course from MIT (course code 6584, I didn’t enroll in the course officially, and I wasn’t a student of MIT). The first issue: The paper specifies that a node should not commit the commands from previous terms directly. Those commands should be committed indirectly by committing the commands from the leader’s current term. At that level, I was not convinced by this constraint, especially after seeing that the initial tests were passing. A simple scenario might be: Suppose we have 3 servers: A, B, and C. In term 1, A becomes a leader. A adds a command X and replicates it to B. A crashes before commit