Tunable Consistency and the PACELC Extension

PACELC extends CAP by acknowledging that even without partitions, systems face a consistency versus latency trade off. If there is a Partition, choose between Availability and Consistency (the original CAP). Else (no partition), choose between Latency and Consistency. Google Spanner is a PC/EC system: it chooses consistency both during and between partitions. Amazon DynamoDB is a PA/EL system: it chooses availability during partitions and low latency during normal operation.

Modern databases expose this trade off as tunable consistency per request. Cassandra lets you specify consistency level per query: ONE (fastest, least consistent), QUORUM (balanced), or ALL (slowest, most consistent). With replication factor 3, a QUORUM read and write (both hitting 2 replicas) guarantees strong consistency because the quorums intersect. However, this adds latency: p99 can reach 10s of milliseconds as you wait for the slowest replica in the quorum. Consistency level ONE achieves single digit millisecond median latency but risks reading stale data written only to a different replica.

The practical pattern is to mix consistency levels based on operation criticality. A payment processing service might use QUORUM writes for debiting accounts (ensuring durability and consistency) but ONE reads for displaying order history (where staleness of a few hundred milliseconds is acceptable). DynamoDB offers strongly consistent reads within a region (adds one extra hop to reach the leader) versus eventually consistent reads (any replica, faster). During an availability zone partition, strongly consistent reads may fail while eventually consistent reads continue serving potentially stale data.

💡 Key Takeaways

•PACELC recognizes that consistency versus latency trade offs exist even without network partitions; strong consistency requires coordination (quorum waits) that adds milliseconds to every operation

•Cassandra QUORUM with replication factor 3 (read 2, write 2) provides linearizability with intersecting quorums but p99 latency reaches 10s of milliseconds waiting for slower replicas; CL ONE achieves single digit ms but risks stale reads

•DynamoDB strongly consistent reads add an extra network hop to reach the authoritative replica (typically 1 to 3ms overhead); eventually consistent reads hit any replica for minimum latency but may return stale data

•Per request tuning lets you apply strong consistency to critical paths (QUORUM for account balance updates) and eventual consistency to high volume paths (ONE for feed reads), optimizing for both correctness and performance

•Google Spanner is PC/EC (consistency always), Amazon DynamoDB is PA/EL (availability and latency), Cassandra is tunable per operation; choose based on whether your workload prioritizes correctness or speed

📌 Examples

E commerce checkout: use QUORUM writes to deduct inventory (prevent overselling) but ONE reads to display product catalog (stale stock count acceptable for a few hundred milliseconds)

Social feed: write new posts with CL ONE for fast ingestion (single digit ms), read timelines with CL ONE (maximize throughput), use anti entropy to converge; occasional missing post for seconds is tolerable

Banking app: strongly consistent reads for account balance display (user must see accurate amount before transfer), eventually consistent reads for transaction history list (delay of 1 second acceptable)

Cassandra at Apple (reported): billions of operations per day mixing CL ONE for high throughput ingestion and CL QUORUM for reads requiring accuracy, tuning per table and operation type

← Back to CAP Theorem Overview