principletypescriptTip
CAP theorem in practice: consistency vs availability trade-offs for microservices
Viewed 0 times
cap theoremconsistencyavailabilitypartition tolerancecpappacelcdistributed systemsBrewer's theorem
Problem
Engineers design a distributed system assuming they can have strong consistency, high availability, and partition tolerance simultaneously. Network partitions happen in production, causing unexpected behaviour that was not designed for.
Solution
Accept that all distributed systems must tolerate partitions (P). The real choice is between CP (consistent during partitions — some requests fail) and AP (available during partitions — may serve stale data). Make an explicit design decision per data store and per operation.
CP examples: ZooKeeper, etcd (leader election, config)
AP examples: Cassandra (default), DynamoDB (default), DNS
CP examples: ZooKeeper, etcd (leader election, config)
AP examples: Cassandra (default), DynamoDB (default), DNS
Why
During a network partition, a node must choose: reject requests to stay consistent (CP) or serve potentially stale data to stay available (AP). There is no third option. Understanding this drives correct system design.
Gotchas
- CAP applies to a single operation, not an entire system — a system can be CP for writes and AP for reads
- PACELC extends CAP to cover the latency vs consistency trade-off even when there is no partition
- Strong consistency is achievable in a single data centre with synchronous replication at a latency cost
- Most applications need AP for reads and CP for writes — design accordingly
Context
Choosing data stores and designing data access patterns for distributed services
Revisions (0)
No revisions yet.