Proposing Design Options in an Architecture Discussion.

Now you move into higher-stakes collaboration: design decisions. In this lesson, Northbank Digital needs a change to the API that could affect performance and operational load. You join an architecture discussion with engineering, SRE and Product, and you practise proposing options, comparing trade-offs, and inviting critique without sounding uncertain or defensive. You will work with a model discussion where speakers structure their points, use evidence, and keep the tone constructive. You will practise language for criteria (performance, reliability, security, maintainability, cost) and for responsible risk framing (“My concern is…”, “The trade-off is…”). You will also practise closing the discussion with a clear decision and next steps. Your artefact is a short design note section (ADR/RFC style): options considered, recommendation, and risks to validate. The aim is clarity that travels well to colleagues who were not in the call.

1. Join the architecture call and set the goal.

Right, let’s drop into today’s situation at Northbank Digital. You’re joining a live architecture discussion about an API change. Product want a new capability quickly, SRE are worried about operational load, and Engineering are thinking about performance and long-term maintainability. Your job in this lesson is not to “win” the discussion. It’s to sound calm and credible while you propose options, compare trade-offs, and invite critique. In a good design discussion, people keep coming back to two things: what we’re optimising for, and what risks we’re accepting or reducing. So, as we start, I want you to picture yourself as an engineer who can structure points clearly. You’ll hear a short excerpt from the call. As you listen, focus on three things: how speakers introduce options, what criteria they use to compare them, and how they frame concerns without sounding negative. After that, you’ll summarise the goal and the options in one or two crisp sentences, as if you’re taking notes for the team.

Situation: an API change with real consequences.

You’re on a remote call with Engineering, SRE, and Product. There’s a proposal to change an API endpoint used by multiple clients. The change could make the product more flexible, but it might also increase latency and create more operational load (more cache misses, more DB pressure, more on-call noise).

In this lesson, your “can do” outcome is:

• You can propose two or more design options, compare them using clear criteria, and close with a decision plus next steps.

What “good” sounds like (at B2).

In high-stakes technical collaboration, sounding credible is often about structure and careful certainty.

You will hear speakers do things like:

• define the decision: “What are we optimising for in this release?”
• present options: “I see two realistic options here…”
• compare with criteria: “From a performance perspective…” / “Operationally, this would mean…”
• frame concerns responsibly: “My concern is…” / “I’m not against it, but I’d like to validate…”
• move towards closure: “Shall we agree a decision and capture it?”

Call cast (keep these names throughout).

• Maya (Product Manager): wants a timeline and user impact.
• Alex (Backend Engineer, you): proposes options and trade-offs.
• Sam (SRE): focused on failure modes, on-call load, and reliability.

Mini checklist for your notes.

As you listen, capture:

1. The two options (label them A and B).
2. The criteria used (performance, reliability, security, maintainability, cost).
3. One open question that needs validation.

When you write your answer for this block, aim for a short “meeting note” style. Clear, not perfect.

Useful phrases (you’ll reuse them later).

• I see two realistic options here.
• Option A would…, whereas option B would…
• The main trade-off is…
• What are we optimising for in this release?
• Shall we agree a decision and capture it?

Practice & Feedback

Listen to the short excerpt from the architecture call. Then write 2–3 sentences as if you are taking live notes for the team.

Include:

• Option A and Option B (even if your wording is simple).
• One criterion used to compare them (performance, reliability, security, maintainability, cost).
• One open question to validate.

Keep it practical and concise, like something you would paste into Slack after the call. Use at least one phrase from the useful phrase list on the screen.

2. Notice option language and trade-off framing.

Now we’ll zoom in on the language that makes your contribution sound organised rather than improvised. In design discussions, you’re often thinking in real time, but you still need to communicate in neat “packages”: options, criteria, trade-off, and what to validate. In a moment you’ll read a short transcript-style extract. I want you to notice how the speaker avoids sounding either overconfident or vague. Instead of saying “This is bad”, they say “My concern is…” and then they attach the concern to a criterion like reliability or maintenance cost. That’s what makes it professional. As you read, underline in your mind: one phrase for introducing options, one phrase for comparing options, and one phrase for responsible uncertainty. Then you’ll rewrite a few lines to match a specific aim: sound collaborative, invite critique, and still push the discussion forward. That combination is what senior engineers do constantly.

Read the model extract (and look for the structure).

In the last block you heard the call. Here’s a written extract with a bit more detail. Don’t read it like a novel. Read it like an engineer: spot the moves.

Moves to spot:

• introducing options
• comparing using criteria
• framing risk responsibly
• inviting critique

Model extract (call transcript style).

Alex (Backend): I see two realistic options here. Option A would add server-side filtering behind the existing endpoint. Option B would introduce a new endpoint with a stricter contract and we’d deprecate the old one over time.

Sam (SRE): From a reliability perspective, my concern is increased DB load during peak usage. Operationally, this would mean higher alert volume and potentially more paging.

Alex: The main trade-off is speed of delivery versus long-term maintenance cost. I’m not against Option A, but I’d like to validate the expected traffic pattern and the failure modes. Can someone sanity-check the failure modes with me?

Maya (PM): What are we optimising for in this release? If we prioritise time-to-market, we may need to accept some risk and mitigate it.

What to copy (high-value chunks).

Notice how these chunks give you a calm, credible tone:

• “I see two realistic options here.” (signals structure)
• “Option A would…, whereas option B would…” (signals comparison)
• “From a performance perspective…” / “From a reliability perspective…” (signals criteria)
• “Operationally, this would mean…” (connects design to on-call reality)
• “My concern is…” (professional caution)
• “I’m not against it, but I’d like to validate…” (collaborative uncertainty)
• “Can someone sanity-check…?” (invites critique)

Micro-skill: trade-off sentence pattern.

A strong trade-off sentence often follows this pattern:

> The main trade-off is X versus Y. If we go with A, we’ll need to B.

Example:

> The main trade-off is shipping quickly versus limiting operational risk. If we go with Option A, we’ll need to add rate limiting and monitoring from day one.

In the task below, you’ll rewrite lines to match specific intentions. Aim for natural British workplace English: direct, but not aggressive.

Practice & Feedback

Read the extract. Then do this short rewriting task.

Write three improved sentences (one for each intention below). Keep the same technical meaning, but use the language on the screen.

1. Introduce options (make it sound structured).
2. State a concern (make it sound professional, not negative).
3. Invite critique (make it collaborative).

Make each sentence one line. You are Alex on the call. Try to use at least two chunks exactly as written (for example: “I see two realistic options here.” / “My concern is…” / “Can someone sanity-check…?”).

Rewrite these basic lines into more professional architecture-discussion English:

A) “We can do it two ways.”

B) “This might cause problems for SRE.”

C) “Can someone check if this is okay?”

3. Compare options using clear criteria.

Let’s move from general phrases to the substance: comparing options with criteria. In real architecture calls, people often talk past each other because they’re using different evaluation standards. One person is optimising for delivery speed, another for reliability, another for security. Your English needs to make the criteria explicit. So in this block, you’ll practise a very practical skill: making a short, readable comparison. You’ll use a simple grid: performance, reliability, security, maintainability, and cost. The aim isn’t to create a perfect architecture document. It’s to sound like someone who has thought it through. You’ll also see a useful pattern: start with one criterion, give a concrete implication, then move to the next. For example, “From a performance perspective…” followed by “Operationally, this would mean…”. That link is especially powerful when SRE are in the room. After the explanation on screen, you’ll complete a mini comparison for Option A and Option B. Keep it short, but be specific.

Why criteria language matters.

When you say “This is better”, the team will ask: better how? Criteria language answers that question in a calm, engineering-friendly way. It also helps you disagree without turning it into a personal debate.

In our scenario, we’re deciding between:

• Option A: add server-side filtering behind the existing endpoint.
• Option B: create a new endpoint with a stricter contract; deprecate the old one later.

A simple comparison table you can reuse.

Below is a model comparison. Notice it doesn’t pretend to be certain. It makes assumptions visible.

The sentence frames (copy and paste mentally).

You don’t need to speak in bullet points, but you can think in them.

• From a performance perspective, …
• From a reliability perspective, …
• Operationally, this would mean …
• The main trade-off is … versus …
• If we go with this approach, we’ll need to …

Micro-skill: “responsible uncertainty”.

At B2, a strong professional tone often avoids absolute claims:

• instead of “This will break production” → “The risk is that this could increase DB load during peak times.”
• instead of “Option B is best” → “Option B looks safer long-term, but we should validate…”

In the task, your goal is to write a compact comparison that would make sense to someone who joined the call late. Clarity travels.

Practice & Feedback

Write a short comparison for the team.

You are Alex. Write 5–7 lines total, in this format:

• One line starting “Option A:”
• One line starting “Option B:”
• Then 3–5 lines comparing criteria (performance, reliability, security, maintainability, cost). You can choose which criteria to mention, but include at least three.

Use at least three of these frames: “From a performance perspective…”, “Operationally, this would mean…”, “The main trade-off is…”, “If we go with this approach, we’ll need to…”. Keep the language realistic, not academic.

Facts you can assume for this exercise:

• Current endpoint is widely used by clients, including large accounts.
• Some filters would require database queries that are not currently indexed.
• SRE have reported that the database is already close to peak capacity during certain hours.
• Product would like the first version in the next release, but can accept a phased rollout if needed.
• The team can add monitoring and rate limiting, but it will take extra effort.

4. Run a short chat-style simulation in the call.

Now we’ll simulate the live call itself, because this is where English can get tricky. You’re thinking technically, you’re responding to questions, and you need to keep your tone constructive. In a good discussion you don’t just present your idea; you invite critique and you help the group converge on a decision. In this chat-style simulation, you will reply as Alex. Maya will push for speed and a clear recommendation. Sam will push on reliability and failure modes. Your aim is to do three things: first, keep the structure of “options and trade-offs”; second, show responsible uncertainty by naming what needs validation; and third, keep the discussion moving with a next step. While you write, imagine you’re speaking on a call: short turns, clear sentences, and you check alignment. Use the chunks you’ve practised: “My concern is…”, “I’m not against it, but…”, and “Shall we agree…?”. After you respond, you should feel you’ve held your ground without sounding defensive. Let’s do it.

Live simulation: keep the tone constructive.

In a real architecture discussion, people will challenge your proposal. That’s healthy. Your job is to treat challenges as data, not as personal criticism.

Your role.

You are Alex (Backend Engineer). You’re speaking to:

• Maya (PM): wants clarity, timeline, and what to tell stakeholders.
• Sam (SRE): wants to avoid operational pain and unclear failure modes.

How to sound credible under pressure.

Use a simple three-part move:

1. Acknowledge the question/concern.
2. Answer with criteria (performance, reliability, maintainability, security, cost).
3. Move forward (validation step, decision, or owner).

Example moves:

• “Good point. From a reliability perspective, my concern is… Operationally, this would mean… If we go with this approach, we’ll need to…”
• “I’m not against Option A, but I’d like to validate traffic patterns first. Can someone sanity-check the failure modes?”
• “What are we optimising for in this release? If time-to-market is the top priority, we can mitigate risk by…”

The goal of this simulation.

By the end, you should have:

• a clear recommendation (even if it is conditional),
• one or two concrete validations,
• and a proposed next step that sounds like a real team decision.

Remember: you can recommend a phased plan. For example: ship a safe first step now, then evolve the contract later.

In the activity below, write it as a mini back-and-forth in chat format, as if you’re replying on a call transcript or in a meeting notes doc.

Practice & Feedback

Write a short chat-style simulation with 4 turns. Use this exact format:

• Maya: …
• You (Alex): …
• Sam: …
• You (Alex): …

In your two replies as Alex:

• Present or refer to two options.
• Use at least two criteria (for example performance + reliability).
• Include one validation step (“I’d like to validate…”) and one move to closure (“Shall we agree…?” or similar).

Keep it natural and concise, like real call talk. Aim for 80–120 words total.

Maya: We need something in the next release. Can you recommend an approach we can commit to?

Sam: Before we commit, can we sanity-check the failure modes? I’m worried this will increase DB load and on-call noise.

5. Close the discussion with a decision and next steps.

You’ve done the hard part: options, trade-offs, and handling pushback. Now we need a clean close. Many design discussions fail not because the engineers are wrong, but because the outcome is vague. People leave the call with different interpretations, and then the work drifts. In this block, you’ll practise how to close decisively without pretending you have perfect information. The trick is to separate: what we’ve decided, what remains an open question, and what we’ll do next to validate the risk. I’m going to show you a short “closing summary” that Alex delivers at the end of the call. Notice the language: “So the decision is…” and “If we go with this approach, we’ll need to…”. It’s firm, but still realistic. Then you’ll write your own closing message as if you’re about to end the meeting and post a quick recap in the thread. You’ll include owners and timeframes, because that’s what turns talk into action.

The closing move: decision, actions, and time.

At Northbank Digital, people are busy and remote. If you don’t close clearly, the discussion will reopen again and again.

A strong close has three sections:

1. Decision (or provisional decision)
2. Open questions / risks to validate
3. Next steps with owners and deadlines

Model closing summary (what it can sound like).

Here’s an example of Alex closing the call:

> Just to recap what we’ve agreed so far: we’ll go with Option A for the next release, but behind a feature flag and with rate limiting. The main trade-off is time-to-market versus operational risk.

>

> My concern is DB load during peak usage, so we’ll validate expected traffic patterns and sanity-check the failure modes before we roll out broadly.

>

> Next steps: I’ll draft the API changes and a rollout plan today. Sam, could you review the monitoring and alerting needs by tomorrow? Maya, can you confirm the success criteria and the biggest customer impact by end of day? Shall we agree to check in on Thursday and capture the decision in the RFC?

Phrase bank for closure (copyable).

• Just to recap what we’ve agreed so far…
• So the decision is…
• The open question is…
• My concern is…, so we’ll validate…
• If we go with this approach, we’ll need to…
• Next steps: … (owner: …, due: …)
• Shall we agree a decision and capture it?

Mini rubric for your own close.

When you write your close in the task below, check:

• Clarity: Could someone who missed the call understand the decision?
• Credibility: Do you avoid absolute promises and show responsible uncertainty?
• Actionability: Are owners and deadlines explicit?

In the next block, you’ll turn this into a short design note section (ADR/RFC style). For now, focus on the spoken/written closing that makes everyone aligned.

Practice & Feedback

Write a closing recap that you could either say at the end of the call or paste into the meeting thread.

Write 120–160 words as Alex.

Include these headings exactly:

• Decision:
• Trade-off:
• Risks / validations:
• Next steps (owner + due):

You can choose Option A, Option B, or a phased approach, but you must make it clear. Use at least four phrases from the phrase bank on the screen. Keep the tone calm and practical, not dramatic.

Call outcome constraints for this exercise:

• Maya wants something shippable next release.
• Sam is okay with moving fast only if rollout is controlled and monitoring is strong.
• The team can use a feature flag and staged rollout.
• There is still uncertainty about peak traffic patterns for large accounts.

Choose a decision that fits these constraints and write your recap.

6. Write the ADR/RFC design note section.

Time to produce the artefact for this lesson: a short design note section, the kind you’d put in an RFC or an ADR. This is where your English really pays off, because the document needs to travel to colleagues who weren’t in the call. A good design note is not a massive essay. It’s a structured summary: options considered, recommendation, and risks to validate. The language should be calm and precise. You want to show that you evaluated criteria like performance, reliability, security, maintainability, and cost, and that you’ve turned uncertainty into concrete validation steps. In the template on screen, you’ll write three mini sections. Keep them readable. Use the chunks you’ve practised: “Option A would… whereas option B would…”, “The main trade-off is…”, “My concern is…”, and “If we go with this approach, we’ll need to…”. When you finish, you’ll have something you can genuinely reuse at work: a clear decision record that reduces rework and avoids arguments repeating in Slack next week.

Your deliverable: a mini RFC/ADR section.

You’re going to write a compact design note that documents the decision from the architecture discussion.

This is what teams want from an ADR/RFC section:

• Options considered: show you evaluated realistic alternatives.
• Recommendation: state the choice and why.
• Risks to validate: list what needs confirmation before broad rollout.

Template (copy the structure).

Use this structure and keep each section tight:

Context (2–3 sentences):

Explain the problem and why it matters now.

Options considered:

• Option A: …
• Option B: …

(Optionally) Option C (phased plan): …

Recommendation:

State the decision and give 2–3 reasons using criteria language.

Risks / validations:

List 3–5 bullet points that are phrased as actions or checks.

Model language you can reuse.

Here are some model sentences that fit naturally in ADR/RFC writing:

• I see two realistic options here. Option A would…, whereas option B would…
• From a performance perspective, …
• From a reliability perspective, … Operationally, this would mean …
• The main trade-off is … versus …
• My concern is …, so we should validate …
• If we go with this approach, we’ll need to …

A strong “Risks / validations” list is measurable.

Good items:

• Validate peak traffic patterns for large accounts (request numbers from Analytics).
• Load test server-side filtering with representative filters; confirm p95 latency target.
• Define and implement rate limiting thresholds; agree go/no-go criteria.
• Sanity-check failure modes (DB saturation, cache stampede) and monitoring/alerts.

Less good items (too vague):

• Check performance.
• Make sure it’s reliable.

In the activity below, write your own mini design note. Don’t worry about being perfect; focus on being clear and credible.

Practice & Feedback

Write your mini RFC/ADR section as Alex.

Length: 180–230 words.

Use these headings exactly:

• Context:
• Options considered:
• Recommendation:
• Risks / validations:

Requirements:

• In “Options considered”, include at least two options (A and B). You may add a phased Option C if you want.
• In “Recommendation”, use at least three criteria (performance, reliability, security, maintainability, cost).
• In “Risks / validations”, include 3–5 items that sound like concrete checks or actions.
• Use at least six chunks from the lesson (for example: “The main trade-off is…”, “Operationally, this would mean…”, “I’m not against it, but…”, “Can someone sanity-check…?”, etc.).

Reminder of the scenario details you can use:

• Product needs more flexible filtering in the reporting API.
• Current endpoint is heavily used by large accounts.
• Some filters may require unindexed queries.
• SRE are concerned about DB load and alert volume.
• A staged rollout with feature flags and monitoring is possible.

Write a design note that a colleague could understand without attending the call.