1. 8
  1.  

  2. 1

    The most interesting point is the one at the end:

    Note that the leader in both Raft and Paxos might become a bottleneck as all the traffic goes through it. The leader handles O(N) messages [per write, where N=# of participants], while a non-leader handles O(1).

    There are other Paxos-based protocols that support multiple leaders such as Mencius [10] or order non-conflicting requests in parallel such as Egalitarian Paxos or Generalized Paxos [11, 12]. It would be great to see Raft-based protocols with similar optimizations.

    1. 1

      EPaxos makes a lot of trade-offs around complexity and applications must specify causality of their mutations, rather than “here’s some generic data, triplicate it”. I’m kind of a skeptic about the need for anything more complex than multipaxos / raft for most use cases. I see this as a great example of where big O is not super helpful. If you want to go crazy, just use raft election safety properties to implement a chain replication topology. For replication factors of 3 you will be blocking on the first ack to the leader no matter what, but the additional replication overhead shifts down the chain. It adds a lot of complexity to maintain the chain, so this will lead to a buggier or more expensive implementation.

      1. 1

        On the other hand, mutation causality is frequently self-evident, e.g., commands to a KV store conflict if they touch the same key; and, once proper, tested and safe epaxos implementations exist in the wild, there’s no compelling reason to choose raft or multipaxos instead.