A partition is a concrete failure scenario
Imagine two replicas serving reservations for the last seat at an event. They can both answer clients, but the network between them stops delivering messages. A write succeeds on replica A. A later read at B cannot discover that write while the partition lasts.
B can wait or reject the operation, or it can answer from its local state. The first choice sacrifices availability for that operation; the second cannot promise the latest value. This is the decision CAP helps expose. It is not a general instruction to buy two of three database features.
The guarantees have precise meanings
In the CAP formulation for a read/write register, consistency means linearizability: operations appear to take effect in one order that respects completed operations in real time. Availability requires each request at a non-failed node to receive a valid operation response, rather than a generic unavailable error; the formal definition does not impose a practical latency deadline. A partition allows communication between groups of nodes to fail. These definitions differ from business uptime targets and the invariant-preservation meaning of consistency in ACID transactions.
The discussion by Gilbert and Lynch explains why an unreliable network prevents guaranteeing both properties for this service. The important distinction is the guarantee under failure, not a label for an entire product.
Interactive: CAP Theorem
Assume a network partition has occurred. Choose which guarantee to preserve: consistency or availability. Outside a partition, both may be possible.
CP (Consistency + Partition Tolerance)
During a partition, a side without the required quorum rejects some requests so successful operations can preserve a single consistent order.
Worked choice: one seat, two regions
Our hypothetical requirement is at most one confirmed reservation per seat. A regional timeout must not create a second winner. Use an authoritative conditional state transition backed by a consensus group, and accept that a side without the required quorum cannot confirm a purchase.
With three voting replicas split two on one side and one on the other, the two-replica side can potentially continue after the protocol establishes a valid leader. The isolated replica must not independently confirm purchases. A majority is necessary here but does not remove other prerequisites such as a healthy leader and durable storage.
A read-only availability page can choose a different behavior: display a stale seat map with a freshness indicator, while treating the final reservation as authoritative. The stale display does not grant ownership. This separates user experience from the safety-critical operation.
If instead both regions sell independently, reconciliation must decide who loses a confirmed reservation. A refund is a business compensation; it does not mean the original at-most-one invariant was preserved.
What quorum arithmetic proves
For a fixed set of N replicas, a write set of size W and a read set of size R intersect if W + R is greater than N. For N = 3, W = 2 and R = 2, any such read overlaps the write set.
That overlap alone does not prove linearizability. A complete protocol must define concurrent-write ordering, partially completed writes, version selection, read repair, membership changes and failures. A read can contact an up-to-date replica yet choose the wrong version. Sloppy quorums may use different replica sets, so the simple intersection assumption also needs checking.
Use quorum arithmetic as one step in a correctness argument. Do not treat a database setting called QUORUM as a substitute for that argument.
Avoid permanent CP/AP labels
A system may expose different read modes, transactions and replication topologies. A stronger mode can reject an operation in conditions where a weaker one could return a stale answer. Specify the operation and deployment mode when comparing systems.
For example, DynamoDB documents read-consistency options and their scope. Do not equate the Dynamo research system with every mode of the DynamoDB service. Similarly, a single-node database can fail and become unavailable; calling it CA is not an uptime guarantee.
Design review exercise
Write a response contract for each path before choosing infrastructure:
| Operation | Required property | Partition response in this exercise |
|---|---|---|
| Confirm a seat | One winner | Reject or wait when authority cannot be reached |
| View a seat map | Approximate availability | Show a dated snapshot, then recheck at confirmation |
| Retry a purchase | No duplicate effect | Reuse an idempotency key and retrieve the prior result |
| Recover after a timeout | Resolve uncertain outcome | Query the authoritative reservation before retrying |
Test by cutting communication after persistence but before acknowledgement. A client timeout means the result is unknown, not necessarily that the write failed. Record which history is acceptable and verify it during recovery.
Continue with replication, Raft and transaction isolation.
Keep reading
Social Feed Design: Fan-out, Ranking and Privacy
Work through a hybrid social-feed design, estimate write amplification, and handle deletion, privacy changes and stable pagination.
Ticket Booking: Durable Holds and Concurrent Checkout
A worked seat-booking design that prevents stale holds from becoming sales and handles payment completion after expiry.
URL Shortener: Allocation, Redirects and Revocation
Design short-link allocation with collision handling, explicit redirect caching, safe revocation and realistic storage estimates.
File Synchronization: Versions, Conflicts and Recovery
A worked file-sync design: immutable blocks, version checks, offline conflicts, and safe cleanup. Includes a clearly scoped Dropbox engineering reference.
Horizontal Scaling (Scaling Out)
The definitive guide to adding more servers to your infrastructure pool and testing the bottlenecks that limit growth.
Leader Election
Comprehensive guide to distributed leader election algorithms including Raft, Paxos, and Bully algorithm, covering consensus, split-brain prevention, and real-world implementations in Kubernetes, ZooKeeper, and etcd.