Classic Paxos and Raft assume one log, one leader, and one consensus group. That works until your throughput ceiling hits the leader's CPU, NIC, or fsync latency. Horizontal Paxos is the architectural move to shard the replicated log itself: partition the keyspace, run an independent Paxos group per shard, and let each group have its own leader on a different machine.

The insight: consensus doesn't have to be a single ordered stream. If operations on key A never need to be ordered with operations on key B, they can live in different logs with different leaders. You've just multiplied your write throughput by the shard count — at the cost of losing global ordering.

How it works in practice:

• Hash or range-partition your keyspace into N shards.
• Each shard runs its own Paxos/Raft group (typically 3 or 5 replicas).
• Place leaders on different physical nodes so no single machine is the bottleneck.
• Cross-shard transactions require a coordinator (usually 2PC over the shard leaders).

Real-world example: Google's Spanner runs thousands of Paxos groups, one per tablet (a range of rows). A single Spanner deployment might have 10,000 independent Paxos groups electing leaders concurrently. CockroachDB uses the same idea with Raft — each 64MB range is its own Raft group. When you write to a row, only the 3–5 replicas of that range participate. Your neighbor's write to a different range doesn't share a single fsync queue with yours.

Rule of thumb: If a single Paxos leader can handle ~10K writes/sec (limited by fsync + replication round-trip), then N shards give you roughly N × 10K writes/sec — but only if your workload distributes evenly. A hot key (say, a global counter) still bottlenecks on one shard's leader. Aim for shards where the busiest shard handles under 70% of a single-leader's ceiling; that leaves headroom for rebalancing.

The trade-offs that bite:

• Cross-shard transactions cost more — you're paying 2PC latency (two round-trips) instead of one Paxos round.
• Rebalancing is nontrivial — moving a shard to a new group requires a coordinated handoff, often via a special reconfiguration log entry.
• Hot shards break the model — one popular key can undo all your scaling. Watch for this in access logs and re-split aggressively.
• Global secondary indexes get painful — they span shards, so you either denormalize or accept async consistency.

Don't reach for horizontal Paxos until you've proven a single group is your bottleneck. The operational cost of thousands of consensus groups (monitoring, failover, split/merge logic) is significant.