Overview
Partition tolerance is a system's ability to keep operating correctly when the network between its nodes drops or delays messages, splitting the cluster into groups that cannot talk to each other. In real networks partitions do happen: switch failures, misconfigured firewalls, cloud network issues, or long garbage collection pauses that look like a dead node.
Because partitions cannot be prevented, any distributed system must decide what to do during one: refuse some requests to stay consistent (CP), or keep answering with possibly stale or conflicting data (AP). This is the practical meaning of the CAP theorem. Designing for partitions includes timeouts, quorum rules, fencing, and conflict resolution.
If branches cannot call each other, they can either stop withdrawals until the line is back (consistent but unavailable) or keep serving customers and reconcile later, risking an overdraft (available but inconsistent).
When to use it
- Any system with more than one node communicating over a network.
- Choosing between CP and AP behavior for each feature.
- Designing multi-region deployments.
- Explaining failure scenarios in interviews.
Where it shows up in interviews
Recognize it when: what happens if regions cannot communicate?
- Design a global inventory system
- Design a shopping cart
Recognize it when: interviewer asks what happens when the network splits.
- Design a distributed lock service
- Design a key-value store
Where it is used in real software
Kyle Kingsbury's Jepsen tests inject network partitions into databases and have found consistency bugs in many popular systems.
Amazon chose availability: carts accept writes during partitions and merge divergent versions afterward.
Choose consistency: the minority side of a partition stops accepting writes.
Key terms
- Network partition
- Nodes are split into groups that cannot communicate.
- CP system
- Stays consistent during partitions by rejecting some requests.
- AP system
- Stays available during partitions and reconciles later.
- Majority quorum
- Only the side with more than half the nodes can make progress.
- Conflict resolution
- Merging divergent writes after a partition heals.
How it works, step by step
- 1Detect the partition
Heartbeats and timeouts; you cannot distinguish slow from dead.
- 2Apply the chosen policy
CP: minority stops writes. AP: every side keeps accepting.
- 3Protect against split brain
Majority quorums and fencing tokens.
- 4Heal
Nodes reconnect and exchange missed updates.
- 5Resolve conflicts
Last-write-wins, vector clocks, CRDTs, or application merges.
STEP 1Healthy cluster: all five nodes replicate to each other.
CP vs AP behavior during a partition
Same partition, different choices
| Feature | Choice | Behavior during partition |
|---|---|---|
| Bank balance | CP | Minority side rejects withdrawals |
| Shopping cart | AP | Both sides accept adds; merge carts later |
| Leader election | CP | Only majority side can elect a leader |
| Social likes | AP | Count increments locally, reconcile later |
NOWFeature: Bank balance | Choice: CP | Behavior during partition: Minority side rejects withdrawals
Partition tolerance is not optional; the real decision is what each feature sacrifices while the partition lasts.
Implementation
// A node accepts writes only if it can reach a majority (CP behavior)async function write(key: string, value: string, peers: Peer[]) { const clusterSize = peers.length + 1; const majority = Math.floor(clusterSize / 2) + 1; const acks = await Promise.allSettled(peers.map((p) => withTimeout(p.replicate(key, value), 200))); const ok = 1 + acks.filter((a) => a.status === "fulfilled").length; // count self if (ok < majority) { throw new Error("Not enough replicas reachable: refusing write to stay consistent"); } return { committed: true, replicas: ok };}Complexity and performance
5 nodes tolerate 2 failures.
Trade-off: fast vs false positives.
Trade-offs
Short timeouts detect failures quickly but misclassify slow nodes as dead; long ones delay recovery.
CP protects invariants but turns partitions into outages for some users; AP keeps serving but requires reconciliation logic.
Variants and related techniques
Else (no partition), systems still choose between latency and consistency.
Cassandra and DynamoDB let each request pick its consistency level.
Common mistakes
- Assuming partitions are rare enough to ignore.
Fix: Design and test the partition behavior explicitly.
- Even-numbered clusters.
Fix: A 2/2 split leaves no majority; use odd sizes like 3 or 5.
Interview questions
Why can't a distributed system give up partition tolerance?
Networks will eventually drop or delay messages. A system that is not partition tolerant simply behaves incorrectly when that happens, so the real choice is between consistency and availability during partitions.
How does a majority quorum prevent split brain?
Only one side of a partition can contain more than half the nodes, so at most one side can elect a leader or commit writes.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Describe CP and AP behavior for 5 features | Easy | Trade-offs. |
| Design partition handling for a multi-region cart | Hard | Merge strategy. |