Consensus & coordination Study Portal

A: Because a crashed peer and a slow peer look identical from the outside: both stop answering. The peer may be paused in garbage collection, its network link may be congested, or its reply may be queued, and any timeout is a guess. Declaring it dead too early risks two nodes acting as leader; waiting too long extends outages. Consensus protocols are built so that a wrong guess costs availability but never correctness — a node wrongly declared dead cannot make decisions without a majority.

A: Because fault tolerance depends on how many nodes can fail while a majority remains, and adding one node to an odd-sized cluster does not change that. Three nodes need two for a majority and tolerate one failure; four need three and still tolerate only one. The fourth node adds cost, network traffic and another machine that can fail, without improving availability. It also makes a two-two network split leave neither side with a majority.

A: To avoid split votes. If every follower timed out at the same moment, they would all become candidates in the same term, each vote for itself, and no one would win a majority; the same would repeat every round. Randomising the timeout within a range means one node usually times out first, requests votes before the others become candidates, and wins, so elections settle in one round most of the time.

A: When the leader of the current term has replicated it to a majority of nodes. Any future leader must win votes from a majority, and a node only votes for a candidate whose log is at least as up to date as its own; since the two majorities overlap, at least one voter holds the committed entry and would refuse a candidate missing it. So every future leader already has every committed entry, and nothing acknowledged to a client is lost.

A: Because correct consensus is subtle and the failure cases are rare enough that bugs survive testing: split votes, stale leaders after pauses, lost acknowledgements, and membership changes. A consensus service has been verified in production and often by formal methods or Jepsen, and it exposes the primitives you need — linearizable compare-and-set, leases that expire with the session, watches and monotonic revisions. Your service then only needs to campaign for a key and respect the lease, which is far less code to get wrong.

A: Because the holder cannot know when its lease has expired if it pauses. A process can acquire a lock, stall for longer than the lease in garbage collection, a VM pause or a slow disk, then resume and act as if it still holds the lock — while another client has legitimately acquired it. Checking the time before acting does not help, since the pause can happen after the check. Correctness needs the protected resource to participate: the lock hands out monotonically increasing fencing tokens and the resource rejects writes carrying an older token.

A: An efficiency lock prevents duplicated work — two workers generating the same report — and occasional double execution is harmless, so a simple lease in Redis is fine. A correctness lock protects an invariant — two writers must never modify an account concurrently — and a violation corrupts data, so it needs a consensus-backed lock service plus fencing tokens checked by the resource. Deciding which kind you need up front tells you how much machinery is justified.

A: Stop acting as leader immediately, not when it believes 10 seconds have passed. Its clock and the server's may differ, and the failure may mean the server already considers the lease expired. It should stop issuing leader-only actions, cancel in-flight work where possible, and keep trying to re-acquire leadership as a normal candidate. Downstream writes should carry its fencing token so that anything still in flight after a new leader starts is rejected.

A: Raft prevents two leaders from committing to the Raft log, but an application leader also acts on external systems. If the old leader is partitioned from the Raft cluster but still connected to the database, it may not yet know it has lost leadership and continues writing while a new leader, elected on the majority side, also writes. The fix is to carry the leadership term or revision as a fencing token on every external write and have the external system reject older tokens, and to make the old leader step down as soon as it cannot renew its lease.

A: They solve different problems. Consensus (Raft, Paxos) makes a group of replicas of the same data agree on the next value, and needs only a majority to proceed, so it survives minority failures. Two-phase commit makes different participants — say two database shards — either all commit or all abort one transaction, and needs every participant's yes, so any single participant or the coordinator failing at the wrong moment blocks it. Production distributed databases combine them: each participant is a consensus group, and 2PC runs across groups.