Using Paxos for consensus among safekeepers.

[phoenix24]

I ask this question without a lot of context as an external observer, if would appreciate if you point me to something where it's already been answered.

safekeeper in it's current implementation rely on paxos for consensus, I've been wondering if raft was considered for the use-case and if so what was the thought process behind it choosing paxos instead.

[arssher]

Current implementation is actually very close to Raft, readme needs an update. The most noticeable difference is the separation of leader, mirroring the general idea of storage separation -- safekeepers only receive records and passively persist it, while stateless compute (Postgres) generates them, acting as a leader. Original Raft paper doesn't mention this idea; on the contrary, in Paxos world, historically roles were as separate as possible -- for example, in Paxos Made Moderately Complex paper you can find even 4 actors (replica, leader from scout + commander, acceptor). Practically always proposers (who proposes records/values) and acceptors (who persist them) are different entities, and that's what we needed here, so we tended to describe things in Paxos terms in the beginning.

As you probably know, there is no single widely accepted Multi-Paxos description detailed enough to be close to real world implementations. It is more generic and Raft can be considered just a variant of Multi-Paxos with certain features. To me, thе key of them is that 1) in Raft log is monotonic, while generic Multi-Paxos runs Synod protocol over each slot (record) almost independently. From this stems the possibility of directly truncating nodes logs to the log of leader; 2) In Raft leader doesn't restamp its term on the older (not committed on the moment of election) entries, from this stems 'can't commit entries from previous terms without generating current term record' rule. And we are like Raft here (though 2) is somewhat reworked to our realms).