TECH ENGLISH

Explaining Architecture Decisions

Learn how to justify your architecture choices in English — explain trade-offs, write ADRs, and present decisions to technical and non-technical audiences.

Practice Tech Discussions

Scenario Context

Your team chose to migrate from a monolithic architecture to microservices. You need to present this decision to stakeholders — explaining why the monolith became a bottleneck, what the trade-offs of microservices are, and how you plan to manage the added complexity of distributed systems.

Why This Matters for Engineers

Every architecture decision involves trade-offs, and the ability to explain those trade-offs clearly separates senior engineers from mid-level ones. Whether you're writing an Architecture Decision Record (ADR), presenting to a team, or justifying a choice to leadership, you need to communicate not just what you chose, but why — and what you chose not to do. Engineers who can frame technical choices in business terms accelerate their path to staff-level roles.

Essential Phrases

We evaluated three options and chose microservices because of the scalability benefits.

Summarizing the decision

formal

The trade-off is increased operational complexity in exchange for independent deployability.

Framing trade-offs

formal

We rejected a modular monolith because our deployment cadence was already a bottleneck.

Explaining rejected alternatives

formal

Let me walk you through the decision matrix we used.

Presenting analysis

neutral

This aligns with our goal of reducing time-to-market by 40%.

Connecting to business goals

formal

The main risk is data consistency across services — here's how we mitigate that.

Acknowledging risks

neutral

We'll use an event-driven pattern to keep services loosely coupled.

Describing implementation

neutral

Think of each microservice as a small, independent business unit.

Simplifying for non-technical audience

casual

The migration will be incremental — we're not doing a big-bang rewrite.

Describing rollout strategy

neutral

This is a reversible decision — if it doesn't work, we can consolidate back.

Reducing perceived risk

neutral

Technical Pronunciation

Word❌ Common Error✅ CorrectTip
microservicesMY-kro-servicesMY-kroh-SUR-vih-sizStress on 'micro' and 'ser'. Don't rush the middle syllables.
monolithMONO-lithMON-uh-lithThree syllables — 'MON-uh-lith'. Think of 'monopoly' start.
scalabilitySCALE-uh-bilityskay-luh-BIL-ih-teeStress on 'BIL'. Five syllables total.
architecturear-chi-TECK-cherAR-kih-tek-cherStress on the first syllable: AR.
resiliencereh-SIL-ee-enserih-ZIL-yuhnsThe 's' sounds like 'z'. Three syllables: rih-ZIL-yuhns.

Written vs. Spoken English

Engineers often write one way on Slack or GitHub, but speak differently in meetings. Here's how to translate.

Justifying a decision

Written (Slack/PR)
ADR-042: Adopt microservices architecture to enable independent deployment and horizontal scaling of individual service components.
Spoken (Meeting)
We're moving to microservices so each team can deploy on their own schedule, and we can scale the parts of the system that need it most.

Discussing alternatives

Written (Slack/PR)
Alternatives considered: (1) Modular monolith, (2) Service-oriented architecture, (3) Microservices. Option 3 selected based on deployment flexibility and team autonomy.
Spoken (Meeting)
We looked at three options. The modular monolith was tempting but doesn't solve our deployment bottleneck. SOA felt too heavyweight. Microservices hit the sweet spot.

Acknowledging risk

Written (Slack/PR)
Risk: Distributed data consistency. Mitigation: Event sourcing with eventual consistency guarantees.
Spoken (Meeting)
The biggest risk is keeping data in sync across services. We'll handle that with event sourcing — so instead of real-time consistency, we accept a small delay in exchange for reliability.

Example Dialogue

YO
YouI'd like to walk you through our architecture decision for the platform migration. We evaluated three options: staying on the monolith, moving to a modular monolith, and adopting microservices.
VP
VP EngineeringWhy not just modularize the existing monolith? That seems less risky.
YO
YouWe considered that. The challenge is that our deployment pipeline is already a bottleneck — even modularized, a single monolith means one deployment process for everything. With microservices, teams can deploy independently, which directly supports our goal of shipping features faster.
VP
VP EngineeringWhat are the risks?
YO
YouThe main risk is data consistency across services. We're mitigating that with an event-driven architecture — services communicate through events rather than direct calls, which keeps them loosely coupled.
VP
VP EngineeringHow long will this migration take?
YO
YouWe'll do it incrementally over three quarters. We'll start by extracting the user authentication service — it has the clearest boundaries and lowest risk. That way we validate our approach before migrating the core business logic.
CT
CTOI like the incremental approach. What if microservices don't work out?
YO
YouGood question. This is a reversible decision. If the complexity outweighs the benefits, we can consolidate services back. But based on teams of similar size at companies like Shopify and Stripe, microservices have proven effective at our scale.

Common Questions

What is an ADR and how do I write one in English?
An Architecture Decision Record (ADR) documents why a decision was made. It typically includes: Title, Status, Context, Decision, Consequences, and Alternatives Considered. Use clear, simple English — an ADR should be readable by someone who joins the team a year from now.
How do I explain architecture to non-technical people?
Use analogies. For microservices: 'Instead of one big restaurant kitchen doing everything, we have specialized food stations that work independently.' For event-driven: 'Instead of asking for updates, we get notified automatically — like subscribing to a newsletter.'
How do I disagree with an architecture decision at work?
Use 'disagree and commit' language: 'I see the merit in this approach, but I have concerns about X. If we go this direction, I think we should add Y as a safeguard. Once we decide, I'm fully committed to making it succeed.'

Stop Stumbling on Tech Calls

Practice explaining code, architecture, and bugs with an AI coach that understands engineering context.

Start Practicing Now

No credit card required.