CAP Theorem
A distributed systems principle stating that a system can guarantee at most two of Consistency, Availability, and Partition Tolerance simultaneously.
The CAP Theorem, formalized by Eric Brewer in 2000, is a fundamental principle governing the design of distributed databases and systems. It states that in the presence of a network partition — a failure that prevents some nodes from communicating with others — a distributed system must choose between Consistency (every read receives the most recent write or an error) and Availability (every request receives a response, though it may not be the most recent data). Because network partitions are an unavoidable reality in distributed systems, the practical choice is between CP (consistent, partition-tolerant) and AP (available, partition-tolerant) designs.
Understanding CAP is essential for architects making database selection decisions. Relational databases running on a single node sidestep the theorem by not being distributed, but as soon as replication or clustering is introduced, trade-offs emerge. Systems like Apache Cassandra and Amazon DynamoDB are designed as AP systems, prioritizing availability and partition tolerance while accepting eventual consistency. Systems like HBase, Zookeeper, and Google Spanner lean toward CP, ensuring consistency even during partitions at the cost of potentially refusing requests until the partition heals.
The PACELC theorem extends CAP by noting that even when there is no partition, a distributed system faces a trade-off between latency and consistency. This refinement is practically important because partitions are rare but latency is a constant concern. A system that replicates synchronously to multiple data centers before acknowledging a write is strongly consistent but slow; one that replicates asynchronously is faster but may serve stale reads. Financial transactions, inventory systems, and medical record updates typically demand strong consistency, while social media feeds, recommendation engines, and analytics dashboards often tolerate eventual consistency in exchange for low latency and high availability.
For compliance-sensitive workloads, the CAP trade-off intersects directly with regulatory requirements. GDPR's accuracy principle, HIPAA's requirements for data integrity, and financial regulations mandating accurate account balances all imply a preference for CP designs in core transactional systems. However, even CP systems must define their behavior during partitions — returning an error is itself a form of availability degradation that must be handled gracefully by upstream services. Architects must document their CAP choices and their implications for data consistency guarantees, especially when those guarantees are subject to audit.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.