How to Present Architecture Decisions in English

Presenting architecture decisions is a high-stakes communication task. You need to explain a complex technical choice clearly, justify it with evidence, acknowledge its limitations, and respond to questions from people with very different levels of technical knowledge.

This guide gives you the language to do all of that in English — from the opening statement to handling difficult questions.

---

Setting the Stage: The Opening

Start by orienting the audience. Tell them what you are presenting and why they are in the room:

“Today I want to walk you through the architecture we’re proposing for the new payments service. I’ll cover the problem we’re solving, the options we evaluated, and our recommendation — and then I’d like your feedback before we move forward.”

“This presentation is about a decision we need to make on the data layer. I’ll keep the technical detail appropriate for this audience and flag where the trade-offs have business implications.”

The phrase “I’d like your feedback before we move forward” is important — it signals that you are genuinely seeking input, not just announcing a done decision.

---

Presenting the Problem First

Never jump straight to the solution. Frame the problem first so the audience understands why a decision is needed:

“Currently, our three microservices each maintain their own copy of the user data. This is causing consistency issues — when a user updates their email address, we’ve had cases where it propagated to two services but not the third.”

“The challenge we’re facing is that our current monolithic database is becoming a bottleneck. As we scale, read queries are competing with write queries, and latency is increasing.”

“We have a window of opportunity: we’re rewriting the notification service from scratch. This is the right time to make a decision about the underlying message broker, because changing it later would be much more expensive.”

---

Walking Through Options

Structure your alternatives clearly:

“We evaluated three options. I’ll walk through each one briefly before explaining why we’re recommending option two.”

Option A:

“The first option was to continue with the existing monolith and optimise queries. The advantage is minimal disruption. The downside is that it’s a short-term fix — we’ll face the same constraint again within 12 months.”

Option B:

“The second option — our recommendation — is to extract the user service as a standalone microservice with its own database. This resolves the consistency problem and gives us independent scaling. The trade-off is a higher initial investment: approximately 6 weeks of engineering time.”

Option C:

“The third option was an event-sourcing architecture. It’s the most powerful of the three but also the most complex. Given our team’s current experience with event sourcing, the risk would be too high at this stage.”

---

Stating Your Recommendation

Be direct:

“Our recommendation is option B — the standalone user service. Here is why.”

“After evaluating all three options, we believe the microservice approach gives us the best balance of risk, cost, and long-term flexibility.”

“We are proposing to proceed with option two, subject to your feedback and sign-off today.”

---

Acknowledging Trade-offs

This is where you demonstrate technical maturity:

“I want to be transparent about the trade-offs. This approach increases operational complexity — we’ll need to manage service discovery and distributed tracing for the new service.”

“The main risk is the migration period: for approximately two weeks, we’ll be running both systems in parallel. We’ve designed a rollback plan for that window.”

“This decision does not solve the caching problem — that is a separate initiative we’ll address in Q3.”

---

Inviting and Handling Questions

Inviting questions:

“I’ll pause here for questions — particularly on the trade-offs section.”

“Does anyone want me to go deeper on any of these options before I move on?”

Handling questions you can’t immediately answer:

“That’s a great question. I don’t have that data to hand right now — let me follow up with you after this session.”

“I want to make sure I give you an accurate answer on that. Can I come back to you with the numbers by end of week?”

Handling disagreement:

“I hear you — that is a valid concern. Can you help me understand the specific risk you’re worried about, so we can address it directly?”

“You’re raising an important point about the operational burden. Can we quantify that together and see if it changes the recommendation?”

---

Closing the Presentation

“To summarise: we’re proposing option B, the standalone user service, starting in sprint 14. We’d like sign-off today so we can begin the migration plan. Any final questions before we close?”

“The next step is to produce a detailed technical design document. I’ll circulate that by end of next week and schedule a follow-up review.”

---

Presenting architecture decisions is a leadership skill, not just a technical one. The clearer your structure and the more honest your trade-off analysis, the more confident your audience will be — in the decision and in you.

Navigating Disagreement with Precision

One of the trickiest aspects of communicating architectural decisions is handling disagreement constructively. It’s easy to fall into accusatory language or simply state your position without acknowledging alternative viewpoints. The key here isn’t necessarily winning the argument, but rather demonstrating that you’ve considered other options and can articulate the reasoning behind your choice. Phrases like “While I appreciate the suggestion of…” or “I understand the rationale for…” immediately soften the tone and show respect for differing opinions. Avoid phrases like “That’s wrong” or “You don’t understand.” Instead, frame it as, “Let’s explore why this approach might not be optimal in this specific context.”

Consider a scenario during a code review: you’ve proposed using a microservice architecture for a new feature, and another developer, Mark, suggests a monolithic design. Mark types: “Microservices seem overly complex here – we’ll just stick with the monolith.” A good response wouldn’t be, “You’re completely misunderstanding the benefits of microservices!” Instead, try something like: “Mark, I appreciate your concern about complexity. While a monolith might simplify development initially, introducing it now could create significant challenges during scaling and future feature additions. Let’s discuss how we can mitigate those risks – perhaps through careful API design or phased rollout.” The phrasing focuses on potential problems rather than directly criticizing Mark’s suggestion.

Another useful technique is to use the “So what?” test frequently. After stating a decision, briefly explain why it matters. For instance, “We’re choosing React for this project because it offers superior performance and developer experience, which will ultimately lead to faster development cycles and reduced maintenance costs.” Don’t just state what you’re doing; clearly articulate the impact.

Finally, when documenting an architectural decision in a PR description, be explicit about trade-offs. It’s not enough to say “Using GraphQL improves performance.” State: “We chose GraphQL over REST because it reduces over-fetching of data, which will improve initial load times and reduce bandwidth consumption – a crucial consideration given our anticipated user base growth.”

Here’s an example using curl for demonstration purposes, showing how you might describe the decision to use an API gateway in a technical discussion:

curl -s https://api.example.com/users?page=2&limit=10

This command illustrates our shift towards a centralized API management solution – the API Gateway – to handle authentication, rate limiting, and routing requests to backend services efficiently. This wasn’t an arbitrary choice; it directly addresses concerns about security vulnerabilities and scalability identified in our initial risk assessment.