English for Architecture Trade-Off Discussions: CAP Theorem and Beyond

Architecture discussions are where the most consequential technical decisions get made — and also where non-native speakers often feel least confident. The vocabulary is dense (CAP theorem, eventual consistency, partition tolerance), and the conversation moves fast. This guide gives you the language to participate fully.

---

The Language of Trade-Offs

Architecture is fundamentally about trade-offs. English has specific vocabulary for framing them:

Contrast structures

• “While strong consistency simplifies the client logic, it comes at the cost of higher latency.”
• “We can optimise for availability at the expense of consistency.”
• “Option A gives us stronger guarantees but introduces operational complexity.”
• “This approach trades write throughput for read simplicity.”

Weighing factors

• “Given our SLA requirements, we prioritised availability over consistency.”
• “The acceptable trade-off here is eventual consistency in exchange for horizontal scalability.”
• “We rejected the stronger consistency model because the overhead was not justified at our scale.”

---

Presenting the CAP Theorem

The CAP theorem (Brewer, 2000) states that a distributed system can only guarantee two of three properties:

• C — Consistency: Every read returns the most recent write.
• A — Availability: Every request receives a response (not necessarily the most recent data).
• P — Partition tolerance: The system continues to operate despite network partitions.

“In practice, partition tolerance is non-negotiable for any distributed system — networks do fail. So the real trade-off is C vs. A during a partition.”

Presenting CAP in a meeting

Opening the topic:

“Before we choose a database, I want to walk through the CAP implications for our use case.”

Framing the choice:

“For our payment service, consistency is non-negotiable — we cannot show a customer a stale balance. So we are willing to sacrifice availability during a partition event. That points us toward a CP system like Zookeeper or a strongly consistent database.”

Acknowledging the constraint:

“For our product catalogue, availability matters more than having the absolute latest price. A brief inconsistency is acceptable. So we can go with an AP system like Cassandra or DynamoDB in eventual consistency mode.”

---

Consistency Models Vocabulary

Beyond CAP, distributed systems discussions involve a spectrum of consistency models:

Model	Meaning	Example sentence
Strong consistency	All nodes see the same data at the same time	”Transactions require strong consistency.”
Eventual consistency	Nodes converge to the same state eventually	”The user profile will be eventually consistent across regions.”
Read-your-writes	A user always sees their own latest write	”We guarantee read-your-writes for session data.”
Monotonic reads	A user never sees older data after seeing newer data	”Monotonic reads prevent confusing UI flicker.”
Causal consistency	Causally related events appear in the right order	”Comments appear after the post they reply to — causal consistency.”

---

Availability vs. Latency vs. Consistency

These three form a common three-way tension:

• “Adding a synchronous replica improves durability but increases write latency.”
• “Caching at the edge reduces latency but introduces a staleness window.”
• “A quorum write (write to majority of nodes) gives us consistency at the cost of higher write amplification.”

Using “vs.” in discussion

• “This is fundamentally a consistency vs. availability decision.”
• “We are debating latency vs. correctness for the reporting pipeline.”
• “The choice comes down to operability vs. raw performance.”

---

Talking About Failure Modes

Architecture discussions should address what happens when things go wrong:

• “If the primary goes down, the secondary takes over within 30 seconds.”
• “During a network partition, the system will reject writes to preserve consistency.”
• “The circuit breaker trips after 5 consecutive failures and enters open state.”
• “A split-brain scenario occurs when both nodes believe they are the primary.”

Hedging appropriately

In architecture, you should acknowledge uncertainty:

• “I am fairly confident that eventual consistency is acceptable here, but I’d like to validate that with the product team.”
• “This is my best estimate — we should benchmark before committing.”
• “There may be edge cases I have not considered — worth a second review.”

---

Discussing PACELC

PACELC (Abadi, 2012) extends CAP: it asks what the trade-off is even when there is no partition (Else: Latency vs. Consistency):

“CAP tells us what happens during a partition. PACELC tells us what happens all the time: do we favour latency or consistency for normal operations?”

• “DynamoDB is PA/EL — available during partition, and optimised for low latency.”
• “Spanner is PC/EC — consistent during partition, and consistent even at the cost of latency.”

---

Phrases for Architecture Review Participation

Asking a question:

“I want to make sure I understand the failure model — what happens to in-flight writes during the failover?”

Challenging a design:

“I think there is a consistency gap here. If two users write simultaneously, what is the conflict resolution strategy?”

Proposing an alternative:

“What if we separate the read and write paths? We could apply CQRS and use an eventually consistent read model.”

Reaching consensus:

“It sounds like we are aligned on eventual consistency for the catalogue, with strong consistency for payments. Is everyone comfortable with that?”

---

Key Takeaways

• CAP theorem: Consistency, Availability, Partition tolerance — pick two. In practice, P is required, so the real choice is C vs. A during a partition.
• Use contrast structures: “while… it comes at the cost of,” “trades X for Y,” “optimises for X at the expense of Y.”
• Know the consistency spectrum: strong → read-your-writes → causal → eventual.
• PACELC extends CAP to normal operations: Latency vs. Consistency even without a partition.
• In meetings, frame your trade-off explicitly before recommending a solution.