story
https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf
Most real-world Paxos implementations, like Raft (what etcd uses), simply use Paxos for electing a leader. Afterward, all updates are serialized through the leader. This was a performance optimization, but it works well only on LANs; it sucks for WANs because you've at least doubled the round-trip time for every commit and the leader becomes a bottleneck, so it's especially important to have low latency.EPaxos was published before Raft and I couldn't find any benchmarks comparing them directly, but in the paper above EPaxos outperforms Mencius (a rotating single leader design) even within a single EC2 cluster. And EPaxos maintains much more consistent performance during latency spikes. So EPaxos may help close the performance gap between LAN and WAN clusters. In the context of IRC where you're geographically distributed _anyhow_, something like EPaxos may impose no appreciable penalty at all, at least if there's sufficient redundancy to ensure a quorum.