CAP Theorem Language — Software Architecture Exercises

1 / 5

A principal engineer states: "The CAP theorem tells us that in the presence of a network partition, a distributed system must choose between consistency and availability." A colleague asks: "So which of the three properties — C, A, or P — can we always guarantee without any sacrifice?" What is the correct answer?

CAP theorem vocabulary — the partition tolerance misconception:

The most important insight in CAP is that partition tolerance (P) is not optional in any system with more than one node communicating over a network. Network partitions — dropped packets, split networks, timeout failures — are an unavoidable reality of distributed systems. You cannot design them away.

The practical choice is therefore: when a partition occurs, do you return possibly stale data (choose Availability) or return an error until consistency is restored (choose Consistency)?

Property	Definition	Can you opt out?
Consistency (C)	Every read returns the most recent write — all nodes see the same data at the same time	Yes — you can sacrifice C to remain available during a partition
Availability (A)	Every request receives a (non-error) response — even if the data may be stale	Yes — you can sacrifice A to guarantee consistency (return errors until quorum is restored)
Partition Tolerance (P)	The system continues operating despite network partitions between nodes	No — in any multi-node distributed system, partitions will happen; P must be assumed

Correct framing for architecture discussions: "The real CAP choice is CP vs. AP — not whether to tolerate partitions, but how to behave when partitions occur."

2 / 5

A DBA says: "MongoDB in its default configuration — with write concern w:1 and read preference primaryPreferred — favours availability over consistency." What does this mean for read behaviour after a network partition that isolates the primary from the secondaries?

CAP vocabulary — AP system behaviour (MongoDB default):

In its default configuration, MongoDB is an AP system during a partition. With primaryPreferred read preference, if the primary is unreachable, reads fall back to a secondary — which may be behind on replication, returning stale data.

MongoDB config	CAP classification	Partition behaviour
`w:1`, `primaryPreferred`	AP — availability preferred	Reads may return stale secondary data; system stays responsive
`w:majority`, `primary`	CP — consistency preferred	Reads only from primary; if primary is partitioned, reads fail until election completes

Key vocabulary for distributed database discussions:

Replication lag: the delay between a write on the primary and its application on a secondary
Read preference: MongoDB configuration controlling which node the client reads from (primary, primaryPreferred, secondary, nearest)
Write concern: the acknowledgement level required before a write is confirmed to the client (w:1 = primary only, w:majority = majority of replica set)
Stale read: a read that returns data not yet reflecting the latest committed write

Architecture discussion phrase: "With primaryPreferred reads, we accept the risk of stale reads during a partition in exchange for continued availability — if your feature requires read-your-writes consistency, you must read from primary only."

3 / 5

An architect mentions PACELC during a discussion about database selection: "CAP only tells half the story — we need to apply PACELC to evaluate this system properly." What does the PACELC model add to CAP that CAP alone does not address?

PACELC vocabulary — extending CAP:

PACELC = PA/ELC: If there is a Partition, choose between Availability and Consistency. Else (no partition), choose between Latency and Consistency.

The key insight: even during normal operation, a system that wants strong consistency must accept higher latency — it must wait for all replicas to acknowledge a write before confirming it. CAP doesn't model this everyday operational trade-off.

System	Partition behaviour (PA/PC)	Normal operation (EL/EC)
DynamoDB (default)	PA — stay available	EL — optimise for low latency
DynamoDB (strong consistency)	PC — prefer consistency	EC — accept higher latency for consistency
Cassandra (tunable)	PA — stay available by default	EL — optimise for write latency
PostgreSQL (synchronous replication)	PC — block until replica confirms	EC — every write waits for replica acknowledgement

PACELC vocabulary phrase for architecture interviews: "The question isn't just what happens during a partition — PACELC reminds us that even in normal operation, requiring strong consistency means accepting higher write latency because the system must wait for cross-node acknowledgement before confirming."

4 / 5

An engineer says: "We need strong consistency on the payment confirmation read — we can't accept eventual consistency here." What property must the system guarantee to correctly claim strong consistency for that read path?

Strong consistency vocabulary — linearizability:

Option A is the correct definition. Strong consistency (also called linearizability) is a specific, formal guarantee: any read that begins after a write completes must return that write's value — no stale reads, no matter which replica services the read.

Consistency model	Guarantee	Example
Strong / Linearizable	Every read returns the most recent write — operations appear instantaneous and globally ordered	Reading payment status immediately after writing "confirmed" always returns "confirmed"
Sequential consistency	All operations appear to execute in some global sequential order — but not necessarily real-time order	Writes from one client appear in order; ordering across clients is not guaranteed in real time
Causal consistency	Causally related operations are observed in causal order by all nodes	A reply to a message is always seen after the original message
Eventual consistency	All replicas will converge to the same value — eventually, given no new writes	Acceptable for profile photos; not acceptable for payment status

Important vocabulary clarification: ACID isolation (even SERIALIZABLE) is a single-node concurrency control guarantee, not a distributed consistency guarantee. A replicated database with SERIALIZABLE isolation on each node can still return stale reads if reads are served from a lagging replica. Strong consistency in the distributed sense requires all reads to go through a single source of truth or a consensus protocol (e.g., Raft-based linearizable reads).

5 / 5

In a system design interview, the interviewer challenges you: "The design you've proposed is CA — it guarantees both consistency and availability. But does a CA system actually work in a distributed environment?" What is the correct, technically informed response to this challenge?

CAP vocabulary — responding to the CA challenge:

Option C is the correct and professionally credible response. It demonstrates deep understanding: CA is not a valid category for distributed systems, and the candidate can articulate the correct framing (CP vs. AP) and even differentiate by feature within the same system.

CAP category	Valid in distributed systems?	Behaviour during partition	Example systems
CP	Yes	Returns error or blocks until consistency is restored	HBase, etcd (Raft), ZooKeeper, Redis Cluster (writes)
AP	Yes	Returns possibly stale data; never returns an error	Cassandra, DynamoDB (default), CouchDB
CA	No — only valid on a single node	Cannot exist: you cannot both stay available AND consistent while a partition exists	Single-node PostgreSQL (no replication)

Advanced interview vocabulary — per-feature CAP classification:
Real systems often have mixed consistency requirements by feature. The strongest answer acknowledges this: "The payment path is CP — I prefer a 503 over a stale confirmation. The notification feed is AP — stale is acceptable and availability is more important than freshness." This level of precision signals senior-level architectural thinking.