Classic Paxos and Multi-Paxos funnel every write through an elected leader. That's one extra round trip on every operation: client → leader → acceptors → leader → client. Fast Paxos, proposed by Leslie Lamport in 2005, asks a simple question: what if the client sent its proposal directly to the acceptors, skipping the leader entirely on the happy path?

The trick is in the quorum math. Classic Paxos needs a majority quorum: ⌊N/2⌋ + 1 acceptors out of N. Fast Paxos needs a larger "fast quorum" — specifically ⌈3N/4⌉ — because without a leader to serialize proposals, two clients might propose different values simultaneously, and you need enough overlap between any two fast quorums to detect the collision.

Rule of thumb: for 5 acceptors, classic Paxos needs 3 votes; Fast Paxos needs 4. For 10 acceptors, classic needs 6; Fast needs 8. You trade fault tolerance for latency.

The happy path saves one message delay — roughly 50% latency reduction on the write path. When two clients collide (both propose different values in the same round), Fast Paxos falls back to classic Paxos with a coordinator to resolve the conflict, which costs an extra round trip. So Fast Paxos wins when collisions are rare.

Real-world example: Google's Megastore used a Fast Paxos variant to replicate across geographically distributed data centers, where the cross-region round trip to a leader could add 100+ ms. By letting clients write directly to acceptors in the local region first, they cut commit latency dramatically for uncontended keys. When two regions wrote the same key simultaneously (rare in a well-partitioned schema), they paid the fallback cost.

When Fast Paxos is the wrong choice:

• High contention on the same key — collisions dominate, and the fallback path is slower than classic Paxos would have been.
• Small clusters — with 3 nodes, Fast Paxos needs all 3 (⌈9/4⌉ = 3), so you can't tolerate any failure during fast rounds.
• Asymmetric networks — if one acceptor is much slower, the fast quorum is bottlenecked by it, erasing the latency win.

The deeper lesson: consensus protocols aren't a fixed cost. You can trade quorum size (fault tolerance) for message delays (latency), or trade optimistic execution (fewer messages when uncontended) for pessimistic fallback (more messages when contended). Fast Paxos is one point on that curve. EPaxos, Generalized Paxos, and Flexible Paxos are others — each optimizing for a different workload shape.