Multi-Paxos and Raft both funnel every write through a single leader. That leader becomes a latency floor: if your leader is in Virginia and your user is in Tokyo, every write pays a 150ms trans-Pacific round trip before it even starts replicating. Egalitarian Paxos (EPaxos) throws out the leader entirely. Any replica can commit any command, and the protocol only coordinates when commands actually conflict.

The trick is command interference. EPaxos tracks which commands conflict (e.g., two writes to the same key). Non-conflicting commands commit in one round trip to a fast quorum. Conflicting commands pay an extra round trip to establish ordering. Because most workloads have low conflict rates, the average latency drops dramatically.

The fast path: a replica receives a command, sends it to a fast quorum (⌈3F/2⌉ replicas in a 2F+1 cluster), and if all agree the command doesn't interfere with anything they've seen, it commits. One round trip. Done.

The slow path: if any replica reports interference, the coordinator falls back to a classic quorum (F+1) and explicitly records dependencies. Two round trips. Still no leader.

Real-world example: a globally distributed key-value store with replicas in Virginia, Frankfurt, and Tokyo. With Raft and a Virginia leader, a Tokyo user's write costs ~150ms one-way to Virginia plus replication. With EPaxos, the Tokyo replica coordinates locally with its nearest fast quorum. If nobody else is writing to the same key (the common case), the write commits in ~80ms — nearly half the latency. CockroachDB and Cassandra's LWT-like paths borrow ideas from this space for the same reason.

Rule of thumb: EPaxos wins when your conflict rate is below ~25%. Above that, the slow-path overhead swamps the fast-path savings and you'd have been better off with Multi-Paxos. Measure conflict rate as: (commands that touched an already-in-flight key) / (total commands). If you can't estimate it, assume workloads with a hot key distribution (Zipfian) will exceed the threshold quickly.

The catch: EPaxos is significantly more complex to implement correctly than Raft. Dependency graphs must be tracked, transmitted, and executed in a consistent order across replicas. Recovery after a failure requires reconstructing the interference graph from surviving replicas — a subtle protocol that has had published bugs. Most teams reach for Raft first; EPaxos only earns its complexity when geo-latency is the dominant cost.