Vocabulary

English for Architecture Discussions: The Phrases Senior Engineers Actually Use

June 2025 · 8 min read

System design discussions in English have their own vocabulary. Words like "trade-off", "blast radius", "coupling" and "idempotent" appear constantly in architecture reviews, design documents and technical interviews. Understanding them is one thing — using them fluently in conversation is another.

This guide covers the most useful vocabulary for architecture discussions, with example sentences you can practise out loud.

Trade-off language

Architecture is fundamentally about trade-offs. Being able to articulate them clearly separates a strong communicator from a weak one.

trade-off

A situation where gaining one benefit requires accepting a cost or disadvantage.

"The trade-off here is that we get lower latency but at the cost of consistency — during a partition, clients may read stale data."

the downside / the upside

The negative / positive consequence of a decision.

"The upside is horizontal scalability. The downside is that we lose transactions across partition boundaries."

to weigh (options against each other)

To carefully compare alternatives.

"We weighed batch versus streaming and decided that the additional operational complexity of streaming wasn't justified at our current data volumes."

Key phrases for presenting trade-offs

"The main trade-off we considered was X versus Y."

"This approach gives us [benefit], but it comes at the cost of [cost]."

"We prioritised [X] over [Y] because in our context, [reason]."

System quality vocabulary

bottleneck

A point in the system that limits overall throughput or performance.

"The bottleneck isn't the computation — it's the network I/O between the aggregation layer and the warehouse."

latency

The time delay between a request and a response.

"Our P99 latency was unacceptable for real-time dashboards, so we introduced a pre-aggregated cache layer."

throughput

The volume of data or requests processed per unit of time.

"At peak we need to handle roughly 800,000 events per second — that's the throughput requirement that drove the Kafka decision."

idempotent

An operation that produces the same result regardless of how many times it's applied.

"We made the ingestion step idempotent so that retries don't produce duplicate records."

blast radius

The scope of impact if a component fails.

"By isolating the recommendation service, we limited the blast radius — a failure there won't take down the checkout flow."

Coupling and cohesion

tightly coupled / loosely coupled

Describes how dependent components are on each other's implementation details.

"The legacy system is tightly coupled — a schema change in one service requires updates in five others. The new design is loosely coupled via an event-driven contract."

single point of failure

A component whose failure would cause the entire system to stop working.

"The current architecture has a single point of failure at the coordination layer. We're addressing it with an active-passive replica."

Scalability language

scale horizontally / scale vertically

Add more machines (horizontal) vs. use a larger machine (vertical).

"The stateless API layer scales horizontally easily. The coordination service doesn't — it needs to scale vertically, which has a hard ceiling."

to handle load / to sustain load

To process traffic without degrading.

"Under our load tests, the current setup can sustain 10,000 concurrent users before latency degrades significantly."

Discussing alternatives in a meeting

These phrases signal that you've thought carefully about options, which is the mark of a senior engineer in any discussion:

"We considered [alternative], but ruled it out because [reason]."

"An alternative approach would be [X], which would give us [benefit], but introduces [cost]."

"This is a pragmatic choice given [constraint] — ideally we'd [better approach], but that's out of scope for now."

"I'd push back on [idea] — the risk is that [problem]. Could we instead [suggestion]?"

How to practise this vocabulary

Knowing these words passively is not enough. The goal is to use them naturally in spoken English without pausing to search for the right term. The only way to achieve that is to practise using them out loud in context.

Choose a recent architectural decision you were involved in. Set a two-minute timer. Explain the decision, the alternatives considered, and the trade-offs — using as many of the words above as you can. Record yourself, listen back, and repeat until the vocabulary feels natural rather than deliberate.

Practise architecture discussions with an AI coach

MentorVoice has architecture review scenarios specifically for data engineers — from medallion architecture decisions to Databricks vs Synapse trade-offs — with grammar and vocabulary feedback after every turn.

Try MentorVoice free →