Network Partition

A subset of distributed system nodes can reach each other but not another subset, splitting the cluster into groups that disagree about the current state. Partition tolerance is not optional for a system spanning more than one node; the real choice a partition forces is between consistency and availability for the duration it lasts.

A partition differs from a total outage. Some communication still works: the network has split into two or more groups that can talk within a group but not across groups. A node on one side cannot tell whether a node on the other side is dead or just unreachable, and that ambiguity is the entire problem: any decision made under a partition might be wrong once it heals.

The CAP theorem is often stated as picking two of three properties, but that framing invites a mistake: partition tolerance is not a design choice you can decline for a system with more than one node, because partitions happen regardless of what you configure. The theorem's real content is narrower and sharper: while a partition is in progress, you choose between linearizable consistency and availability for the side of the partition that cannot reach a quorum. Once the partition heals, the question resolves and both sides can be consistent and available again.

Quorum makes that choice mechanical. A cluster of N nodes has a quorum of at least N/2 + 1 nodes, chosen so that any two quorums must overlap by at least one node; this is what makes it impossible for two disjoint groups to both hold a quorum at the same time. CP systems (etcd, ZooKeeper, CockroachDB, Raft- and Paxos-based systems) require a quorum to elect a leader and to commit a write. The majority-side partition keeps a quorum and keeps operating; the minority side cannot reach one, so it refuses writes and, if configured correctly, refuses to serve reads that must be current. This is what makes Raft-committed writes linearizable: no write is acknowledged without quorum agreement, and no minority node can independently believe it holds the latest state. Reads only inherit that guarantee if they are also routed through the leader or use a lease or read-index mechanism; a read served locally by a stale follower is not linearizable even in an otherwise-CP system, which is the read-freshness gap operators most often get wrong.

AP systems such as Dynamo-style stores choose availability by accepting reads and writes from reachable replicas, often using tunable read/write quorums and, in some systems, sloppy quorum and hinted handoff. During a partition, writes can be accepted on sides that cannot coordinate with each other, so replicas may diverge and later require conflict resolution (last-write-wins by timestamp, vector clocks, CRDTs), which can silently drop a write that lost the resolution.

The specific way a partition destroys correctness when leader election has no fencing safeguard, both sides electing their own leader and both accepting writes, is its own failure mode, covered in split_brain; that entity is the concrete data-loss consequence this one sets up.

Cloud occurrence: AWS availability zone network degradation is the most common real-world trigger. Multi-AZ clusters must be designed to tolerate inter-AZ partition as a routine event, not an edge case. Also triggered by aggressive security group rules, subnet routing changes, NAT gateway failures, and DNS resolution failures that make live nodes appear unreachable to cluster membership.