Questions: CAP Theorem

Question 1

A software architect proposes a distributed database that guarantees both Consistency and Availability by sacrificing Partition Tolerance. Why does the CAP theorem expose this as an unrealistic design?

• A. You should always prioritize Partition Tolerance and Availability over Consistency in distributed systems
• B. Network partitions are unavoidable in any real distributed deployment, so a system requiring no partitions cannot be reliably operated
• C. Consistency and Availability are mutually exclusive and cannot be achieved simultaneously under any conditions
• D. The CAP theorem requires all three properties to be traded off in equal proportions

Answer: (B)

The 'CA without P' option sounds appealing but is not achievable in practice: hardware fails, network cables are cut, packets are dropped, and data centers lose connectivity. A system that assumes zero partitions is effectively a single-node system — not a distributed system at all. Because partitions will occur, every real distributed system must choose how to behave when they do: either refuse some requests (CP) or return potentially stale data (AP). The practical choice is always between CP and AP, never CA.

Question 2

A distributed database advertises 'CAP consistency.' A developer assumes this means it enforces data integrity rules such as preventing bank account balances from going negative. Is this correct?

• A. Yes — CAP consistency is equivalent to ACID consistency and enforces application-level invariants
• B. No — CAP consistency (linearizability) means every read returns the most recent write; it makes no claim about application-level invariants
• C. Yes — CP systems automatically implement full ACID compliance as a consequence
• D. No — CAP systems cannot enforce any form of data consistency whatsoever

Answer: (B)

CAP consistency and ACID consistency are entirely different properties that unfortunately share the same word. CAP consistency (formally, linearizability) means: if I write a value, any subsequent read from any node returns that value or a later one. ACID consistency means: the database enforces application-defined invariants (foreign keys, check constraints, business rules). A system can be AP in the CAP sense while still enforcing strong ACID invariants within a single node, or it can be CP yet lack application-level constraint checking. The conflation of these two meanings is one of the most common mistakes in distributed systems reasoning.

Question 3

A CA (Consistency + Availability without Partition Tolerance) distributed database is a viable architecture for production applications where high uptime is critical.

• T. True
• F. False

Answer: False

CA systems do not exist as a meaningful category for distributed deployments. Partition tolerance is not a feature you 'sacrifice by choice' — it is an acknowledgment that partitions will happen whether you want them to or not. Any system that requires zero partitions must either run on a single node (giving up distribution) or will fail unpredictably when the inevitable partition occurs. Modern distributed databases acknowledge this and position themselves as CP (like ZooKeeper) or AP (like Cassandra), never CA.

Question 4

An AP distributed system that returns stale data during a network partition can still eventually reach the correct consistent state once the partition heals.

• T. True
• F. False

Answer: True

This is the definition of eventual consistency: during a partition, AP nodes continue serving requests (possibly with stale data), but once network connectivity is restored, conflict resolution mechanisms propagate updates across all replicas until they converge. The trade-off is predictability during the partition vs. liveness. Cassandra, DynamoDB, and CouchDB all implement eventual consistency this way — they choose to remain available during outages and accept a window of potential staleness that resolves automatically.

Question 5

Why does the CAP theorem reduce in practice to a choice between CP and AP, rather than a genuine three-way trade-off? What makes the third option (CA — sacrificing partition tolerance) unrealistic?

Model answer: Partitions are not optional. In any distributed system spanning multiple machines, network failures, hardware crashes, and connectivity interruptions will occur. A system that 'sacrifices partition tolerance' is claiming it can guarantee no partition will ever happen — an impossible guarantee in real infrastructure. So the real question is not whether to handle partitions, but how: either maintain consistency by refusing some requests when a partition makes it impossible to confirm the latest state (CP), or maintain availability by continuing to respond even with potentially stale data (AP).

The PACELC model extends this insight: even without partitions, there is a latency-consistency trade-off. Stronger consistency (requiring all replicas to agree before responding) takes more coordination time. AP systems also must design conflict resolution strategies (last-write-wins, vector clocks, CRDTs) because divergent replicas will accumulate during partitions and must be reconciled. The CAP theorem is a theoretical result about worst-case behavior during partitions; real system design adds latency, replication lag, and operational complexity to the picture.