Overview
When a distributed system suffers a network partition, it must choose between consistency (every node sees the same data, even if that means rejecting requests) and availability (every request gets a response, even if the data might be stale). This CAP theorem tradeoff shapes how databases behave under failure and directly affects correctness guarantees versus uptime.
Comparison Diagram
Comparison Table
| Aspect | Consistency (CP) | Availability (AP) |
|---|---|---|
| Normal operation (no partition) | Behaves identically to any healthy cluster; all replicas agree | Behaves identically to any healthy cluster; all replicas agree |
| Behavior when a partition occurs | Nodes that cannot confirm quorum stop responding | All nodes keep responding regardless of quorum status |
| Write handling during partition | Writes are rejected or queued until enough replicas are reachable | Writes are accepted locally and replicated once the partition heals |
| Read handling during partition | Reads are blocked or errored if the latest value can’t be confirmed | Reads are served from whatever local replica is reachable, even if stale |
| Client-facing failure mode | Client sees a timeout or explicit error (e.g. 503) | Client sees a successful response that may contain outdated data |
| Data guarantee provided | Linearizability - no two nodes ever disagree on current state | Liveness - the system always answers, correctness may lag |
| Recovery after partition heals | Resumes cleanly; no conflicting writes existed since they were blocked | Must reconcile diverging writes via vector clocks, LWW, or CRDTs |
| Representative systems | HBase, Zookeeper, MongoDB (default majority writes) | Cassandra, DynamoDB, Riak |
Key Differences
- The tradeoff only bites during an actual network partition - outside of that, both behave the same.
- Consistency requires a quorum agreement before answering, which can mean refusing requests.
- Availability guarantees a response but risks returning stale data to the client.
- The choice determines whether you need a conflict resolution strategy for divergent writes after recovery.
- Many production databases offer tunable consistency, letting you pick per-operation rather than a single global stance.
When to Use Each
Consistency (CP)
- Financial transactions: Double-spending or incorrect balances are worse than a temporarily rejected request.
- Inventory and stock counts: Overselling the same unit to two customers is a costlier error than brief unavailability.
- Distributed locks and leader election: Coordination services like Zookeeper must never let two nodes believe they hold the same lock.
Availability (AP)
- Social media feeds: Users tolerate seeing a slightly outdated post far more than they tolerate a broken page.
- Shopping cart services: Accepting an add-to-cart write even during a partition avoids losing a sale, as Amazon’s Dynamo design chose.
- IoT and sensor ingestion: Continuous data collection matters more than perfect ordering across replicas.
- Global CDN and edge caching: Serving cached content during an outage keeps the site up even if it’s briefly stale.