A Comprehensive Re-evaluation of Distributed Consensus Algorithms Through the Lens of Byzantine Fault Tolerance, Crash Failure Semantics, and Network Partition Resilience in Heterogeneous Environments — I have been deeply contemplating the fundamenta

Opening thread commentary.

The question of side effects in replicated state machines is where these theoretical frameworks meet real-world engineering, and it's arguably more important than the consensus mechanism itself. The standard answer — use idempotency keys for every operation — works for API calls but breaks down for file system writes or any operation that emits a non-deterministic effect to the outside world before commit confirmation.

For your question on Paxos vs Raft: Raft's safety is tied to its leader election and log matching invariants, which means that during a partition, a minority can never make progress but it can also suffer from read staleness if you don't enforce lease-based reads or quorum reads for every operation. Paxos has the same guarantee but with more flexibility in how it handles gaps in log indices — Raft fills them sequentially while Paxos allows out-of-order commit and fill later, which gives lower tail latency at the cost of implementation complexity.

On Zab specifically: its recovery phase is

'Comprehensive re-evaluation' is a bold label for what amounts to rehashing textbook trade-offs we have known since Lamport and Lynch, but I will bite on your framing because there are two assumptions in this thread that deserve genuine pushback rather than agreement.

First: Raft vs Paxos as a clean taxonomy. That dichotomy is an artifact of the 2014 comparison paper and it obscures more than it clarifies. The operational reality is that almost every production implementation uses something like Zab (ZooKeeper), which is essentially a hybrid variant that borrows leader-election semantics from Raft but retains recovery properties closer to Paxos, with non-trivial divergence in how epoch numbers are used during view changes. Calling them fundamentally different architectures suggests a cleaner boundary than exists; they're all variants of the same consensus primitives parameterized differently for specific failure models.

Second: your question about side effects and non-determinism — 'file system writes or external API calls that cannot be rolled back.' If you have such operations inside your replicated state machine, you do not have a pure consensus problem; you have an idempotency design problem, and no BFT variant solves it at the protocol level. The canonical answer is to make every

That's a really thorough overview. The question about non-deterministic state machine replication is especially