CAP is about behavior during a network partition: a replicated service cannot guarantee both linearizable responses and a successful response from every non-failing node. It does not mean a database permanently “chooses two of three.”
Name the client-visible guarantee
| Model | Client-visible promise |
|---|---|
| Linearizability | Each operation appears at one instant between call and return |
| Sequential consistency | One global order respects each client’s program order |
| Causal consistency | Causal order is preserved; concurrent writes may differ |
| Eventual consistency | Replicas converge after updates stop, without a freshness bound |
Consistency is not a slider labeled strong/weak. Each model permits specific observations.
Quorums expose a tunable boundary
With replication factor (N), write acknowledgements (W), and read responses (R), the familiar condition (R + W > N) creates overlap. Correctness still depends on version selection, failure assumptions, sloppy quorums, and repair; the inequality alone is not a proof.
Cassandra’s write path
Cassandra partitions keys around a ring and replicates them across failure domains. A replica appends to a commit log, updates a memtable, and later flushes a sorted SSTable. Bloom filters avoid searching SSTables that definitely do not contain a key; compaction merges files and discards obsolete versions.
Hinted handoff, read repair, and anti-entropy help replicas converge. Tunable consistency chooses how many replica responses a request waits for.
HBase chooses a different contract
HBase stores ordered rows in regions backed by HDFS. Region servers maintain a write-ahead log and MemStore, then flush HFiles. Range scans follow row-key order. Coordination and single-region ownership favor stronger consistency, while a partition may make an affected region unavailable.
In plain terms: Cassandra tends to keep more doors open during trouble and reconcile later; HBase is more willing to close a door than serve conflicting views.
Design from access and failure behavior
Choose partition keys, row keys, consistency level, and replication placement together. Ask what a client may read after its own write, what happens when a region or rack fails, how conflicts are represented, and how long convergence can take.
Review card
- CAP applies specifically when communication is partitioned.
- Consistency models are sets of allowed observations.
- Quorum overlap helps only with compatible version and repair rules.
- Cassandra uses append, memtable, SSTable, and background repair.
- HBase uses ordered regions and favors consistent access to an available owner.
- Storage layout and consistency contract must match the workload together.