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.