English for Solution Architects: Trade-Off Language and Design Reviews

Solution architects spend much of their time communicating decisions — in design reviews, ADRs, RFCs, presentations to leadership, and conversations with development teams. The English used in these contexts is precise, structured, and careful about uncertainty.

This guide covers the specific vocabulary, phrase patterns, and document templates that solution architects use to communicate system design decisions effectively in English.

The Core Communication Tasks of an Architect

Proposing a design — presenting a new system, component, or approach
Documenting trade-offs — explaining what was chosen, what was rejected, and why
Running a design review — facilitating technical critique and discussion
Writing an ADR — capturing a decision for the record
Escalating risk — communicating technical risk to non-technical leadership

Part 1: Trade-Off Language

Architecture is never about finding the perfect solution — it is about choosing the best trade-off for the context. The language of trade-offs is the most important tool in an architect’s vocabulary.

Core trade-off vocabulary

Term	Meaning
trade-off	A situation where gaining one property requires sacrificing another
constraint	A limitation that restricts the design space (budget, team size, existing systems)
driver	A factor that heavily influences the design decision
non-functional requirement (NFR)	A quality attribute: performance, availability, security, scalability, maintainability
quality attribute	Synonym for NFR — what “good” looks like beyond just “it works”
fitness for purpose	Whether a solution is appropriate for the specific context
coupled / decoupled	How much change in one component requires change in another
operability	How easy is the system to run in production?

Phrases for expressing trade-offs

Acknowledging the cost of a choice:

“The benefit of X is Y, at the cost of Z.”
“This approach optimises for [availability/latency/consistency], which means accepting [higher cost/increased complexity/weaker consistency].”
“We gain [property] but sacrifice [property].”
“This is a good fit if [condition], but becomes problematic if [condition].”

Comparing options:

“Option A is simpler operationally but introduces tight coupling between [services].”
“Option B has higher upfront complexity but gives us more flexibility as the system grows.”
“Both approaches are viable — the key question is whether [condition X] is more important than [condition Y] for this context.”

Explaining why you rejected an option:

“We considered [option] but ruled it out because [reason].”
“[Option] would have worked, but it would require [cost/dependency/change] that is not justified at this scale.”
“The main concern with [option] is [concern]. It’s not a dealbreaker, but it becomes a significant liability if [scenario].”

Part 2: Design Review Language

A design review is a structured conversation where architects and senior engineers critique a proposed design. The goal is to find weaknesses, validate assumptions, and improve the design — not to attack the author.

Opening a design review

“Thanks for putting this together. Before we get into questions — could you give us a 5-minute overview of the key design decisions and the main constraints you were working with?”

“I’d like us to focus on the areas where there’s most uncertainty first — specifically [component X] and the data flow for [scenario Y]. Does that work?”

Asking probing questions (not attackng)

“What happens to [component X] when [failure scenario]?”
“Have you considered the case where [edge case]?”
“What’s the expected [latency/throughput/error rate] under [peak load]?”
“How does this interact with [existing system]?”
“What are we assuming about [external dependency] that might not hold?”
“What does rollback look like if we need to revert this?”

Flagging concerns constructively

“I have a concern about [X]. Specifically, [explain concern]. I’m not saying it’s a blocker — I want to understand whether [assumption] holds.”
“This feels like it could have [scaling/operational/coupling] issues if [condition]. Am I missing something?”
“The design makes sense for the happy path. My question is around [failure mode] — how are we handling that?”
“I’d push back slightly on [decision]. My intuition is [alternative], because [reason]. What led you to choose [decision] over that?”

Reaching consensus in a design review

“I think we have broad agreement on [X]. The remaining open question is [Y]. Can we time-box 10 minutes to resolve that?”
“This is a judgment call between [option A] and [option B]. Both are defensible. Who has the strongest opinion?”
“My recommendation would be [decision], but I want to hear from [team/person] given their experience with [relevant area] before we commit.”

Part 3: Architecture Decision Records (ADRs)

An ADR documents a significant architectural decision — what was decided, why, what alternatives were considered, and what the consequences are. Writing a good ADR is a core architectural communication skill.

ADR Template

# ADR-042: Use Event Sourcing for the Orders Service

**Status:** Accepted  
**Date:** 2026-03-15  
**Authors:** [name(s)]  
**Reviewers:** [name(s)]  

---

## Context

The orders service currently stores only the current state of each order. 
As the business has grown, three problems have emerged:

1. We cannot reconstruct the history of how an order reached its current state 
   (needed for dispute resolution and compliance audits).
2. Multiple services need to react to order state changes, and our current 
   approach uses polling, which creates lag and load.
3. Debugging production issues requires manual log correlation, which is slow.

---

## Decision

We will adopt event sourcing for the orders service. All state changes will be 
persisted as immutable events to an event store. The current state of any order 
will be derived by replaying the relevant events.

---

## Alternatives Considered

**Option 1: Add an audit log table (rejected)**  
We could add a separate audit table that records all changes as a side effect. 
This solves the history requirement but does not address the event-driven 
integration or debugging problems. It also creates a dual-write consistency risk.

**Option 2: Continue with the current approach and add CDC**  
Change Data Capture on the database would allow other services to react to 
changes. This has lower implementation cost but ties event semantics to database 
schema changes, creating high coupling between internal implementation and the 
event contract.

**Option 3: Full Event Sourcing (accepted)**  
The event log becomes the source of truth. Read models are built as projections 
over the event log. This is more complex to implement but solves all three 
problems and positions us well for future requirements.

---

## Consequences

**Positive:**
- Complete order history available for compliance and dispute resolution.
- Clean event contract for downstream services to consume.
- Debugging becomes significantly easier — we can replay events to reproduce issues.

**Negative:**
- Eventual consistency for read models — queries may return slightly stale data.
  Acceptable given that order state is not required to be real-time for most reads.
- Increased initial implementation complexity (estimated +6 weeks for the 
  migration and new infrastructure).
- Team requires training on event sourcing patterns.

**Mitigations:**
- We will adopt a phased approach: new orders will use event sourcing; 
  existing orders will be migrated in a background job over 8 weeks.
- We will use [specific event store technology] which the team has prior 
  experience with.

---

## Review Notes

*[Space for comments from reviewers during the review process]*

Part 4: Communicating Technical Risk to Leadership

When presenting technical risk to non-technical leadership, you need to translate system complexity into business impact language.

Framing technical risk in business terms

❌ “If we don’t address the N+1 query problem in the user service, the database will become a bottleneck at scale.”

✅ “As we grow beyond 500,000 users — which we expect to reach by Q3 — our current architecture will likely cause [slow page loads / service outages / elevated costs]. We can fix this in 2 sprints now, or face a significantly larger remediation under live traffic pressure later.”

The risk communication formula

The risk (in plain terms): “What could go wrong?”
The trigger (when it becomes a problem): “At what scale/event/date does this become critical?”
The impact (business language): “What is the business consequence?”
The mitigation cost (now vs later): “What does it cost to fix now vs. deal with later?”
The recommendation: “What do you recommend we do, and by when?”

Risk language vocabulary

“This is a latent risk that will surface under [condition].”
“The technical debt here is manageable now but compounds significantly as [factor X] grows.”
“We’re carrying a known risk. The probability is [low/medium/high]. The impact if it materialises is [description].”
“This is not a blocker today, but it becomes one at [scale/date].”
“We have a narrow window to address this before [event/milestone]. After that, remediation becomes substantially more expensive.”

Part 5: RFC Communication

A Request for Comments (RFC) is an open design proposal that invites feedback from the team before a decision is made. The language must be inviting, not defensive.

RFC Introduction template

# RFC: [Title of Proposed Change]

**Author:** [name]
**Status:** Open for comment  
**Discussion deadline:** [date]  
**Target decision date:** [date]

## Summary

One-paragraph description of what is being proposed and why.

## Motivation

What problem are we solving? Why now? What happens if we don't 
act on this?

## Proposal

The detailed proposed approach. Include diagrams if helpful.

## Open Questions

What are you still unsure about? What are the most important 
things you'd like feedback on?

1. [Question 1]
2. [Question 2]

## Alternatives Considered

What did you think about and reject, and why?

Vocabulary Quick Reference

Situation	Phrase
Proposing a design	”My proposal is to… The key drivers behind this choice are…”
Presenting a trade-off	”This optimises for X at the cost of Y.”
Comparing options	”Both options are viable. The question is whether [A] or [B] matters more for our context.”
Flagging a risk	”I want to flag a concern about [X]. Specifically…”
Rejecting an option	”We considered [option] but ruled it out because…”
Acknowledging uncertainty	”This is our best understanding given current information. We’d revisit this as [condition] becomes clearer.”
Pushing back on a decision	”I’d push back slightly on [X]. My reasoning is [Y]. I’m open to being persuaded otherwise.”
Summarising consensus	”I think we have agreement on [X]. The open question is [Y].”