Architecture Pattern Guide

Review Questions and Conversation Practice

Goal

The guide has supplied pattern vocabulary and a decision frame. The final step is rehearsal: asking questions that reveal architecture, answering in a way that exposes reasoning, and turning unresolved assumptions into follow-up evidence.

The durable idea is:

Architecture fluency grows when you can explain the concern, the pattern, and the trade-off in a clear conversation.

The Short Version

A useful review is a learning loop, not a design tribunal:

question -> explanation -> challenge -> evidence -> decision or follow-up
    ^                                                   |
    +---------------------------------------------------+

The reviewer helps the team expose context, assumptions, risks, boundaries, and evidence. The presenting team helps the reviewer understand why the design fits. Both should leave knowing what has been decided, what remains uncertain, who owns the next action, and when the decision will be revisited.

A Reusable Review Question Set

Use the decision frame as a conversation guide rather than a rigid script.

Context and concern

  • What user or business outcome must this system protect?

  • What changed, and why is a decision needed now?

  • Which concern dominates: correctness, latency, resilience, security, cost, change, or something else?

  • Which assumptions would materially change the design?

Requirements and options

  • Which requirements are non-negotiable, measurable, or regulatory?

  • Which qualities are deliberately lower priority?

  • What viable options were considered, including retaining or simplifying the current design?

  • Why were the rejected options weaker in this context?

Flow, boundaries, and failure

  • Walk through the important request, event, workflow, or data path.

  • Where does ownership change, and which contract crosses that boundary?

  • What happens when a dependency is slow, unavailable, duplicated, or inconsistent?

  • Which state is authoritative, and how is correctness restored?

Trade-offs and ownership

  • What did this design gain, and what did it make harder?

  • Which team owns change, security, cost, monitoring, and recovery?

  • Where is shared responsibility likely to create a gap?

  • Under what condition should the decision be revisited?

Verification

  • Which test, metric, audit, reconciliation, or drill proves the main claim?

  • What evidence exists today, and what remains an assumption?

  • What does failure look like to a user and to an operator?

  • Who owns the follow-up, and by when?

Use an Answer Frame, Not a Product Recital

When you need to explain a design in a meeting, use this compact form:

In [context], the main concern is [concern]. We need [requirements]. We considered [options] and chose [decision] because [reason]. We accept [trade-offs]. [owners] operate and recover it. We will verify the choice through [evidence], and revisit it when [trigger].

That answer can be thirty seconds or the outline for an hour-long review. Its value is that it makes missing reasoning obvious. If you cannot fill one field, you have found a useful question.

Practice Scenario 1: Commerce Reliability

Prompt: Checkout sometimes waits for inventory, fraud, fulfillment, notification, and analytics. Campaign traffic makes the entire path fragile. How would you review the redesign?

Strong answer outline:

  • Context: a customer-facing checkout with financial and inventory consequences.

  • Concern: protect a fast, correct customer outcome from unrelated downstream failures.

  • Requirements: define which outcomes must be immediate, which work must be durable, and which state must be reconciled.

  • Options: keep one synchronous path, shorten the request and queue downstream work, publish events, or use an explicit workflow for ordered steps.

  • Decision: keep only customer-critical validation and confirmation in the request path; place suitable downstream work behind durable boundaries.

  • Trade-off: faster isolation introduces eventual completion, duplicate handling, backlog visibility, and recovery work.

  • Ownership and evidence: assign owners for order state, contracts, failed work, and reconciliation; test peak load, dependency failure, retries, and recovery.

The service names can wait. The review first decides what must remain synchronous and what correctness means after the response.

Practice Scenario 2: AI Assistant Safety

Prompt: A support assistant retrieves customer information and can initiate refunds. The team says the model is protected because it sits behind an authenticated API. What would you ask?

Strong answer outline:

  • Separate user authentication from authorization for each retrieved item and tool action.

  • Identify trusted and untrusted instructions, data sources, and tool inputs.

  • Ask which actions require deterministic policy checks, confirmation, limits, or human approval.

  • Compare read-only assistance, constrained tool use, and autonomous execution.

  • Name trade-offs among convenience, latency, autonomy, safety, and support effort.

  • Assign owners for prompts, retrieval quality, access policy, tool contracts, evaluation, incident response, and cost.

  • Verify with task-quality evaluation, adversarial tests, authorization tests, audit trails, staged rollout, and production monitoring.

"It is authenticated" answers only one boundary question. A strong review follows authority and evidence through the entire action path.

Practice Scenario 3: Enterprise Integration

Prompt: A new partner needs order updates. One team proposes synchronous API calls; another proposes events. How do you move the conversation forward?

Ask whether the communication is a request for immediate work, a durable command, or notification that a business fact occurred. Clarify delivery timing, volume, ordering, replay, duplicate handling, schema evolution, partner outages, and data sensitivity. Then compare options against those requirements.

A good decision may use an API for partner queries and a durable event or message path for updates. The important result is not winning "API versus events." It is choosing a contract and failure model that both parties can own and verify.

Practice Scenario 4: Migration Under Time Pressure

Prompt: A data-center exit date is fixed, but the team also wants to redesign the application into microservices during the move. What should the review reveal?

Surface the two concerns: meeting the exit constraint and improving long-term changeability. Compare a staged migration with a combined migration-and-rewrite. Ask which dependencies, data moves, tests, rollback paths, skills, and operating changes each option creates.

The decision might move the existing workload first and modernize selected boundaries later. That trades temporary inefficiency for schedule confidence and smaller failure scope. Verification should include dependency discovery, migration rehearsals, data validation, cutover measures, rollback criteria, and post-move operating evidence.

How to Challenge Without Turning the Review into a Quiz

Good challenges are specific and curious:

  • "Which requirement makes that complexity necessary?"

  • "What happens to the order when this dependency is unavailable for an hour?"

  • "Who receives this alert, and what can they safely do?"

  • "What evidence would change your mind?"

Avoid trivia, surprise product tests, and criticism without a decision consequence. A reviewer can say, "I see an unowned recovery path," and help name the action needed. The aim is a stronger design and shared understanding, not a clever objection.

Practice on Three Time Scales

  • Thirty seconds: State context, concern, decision, and main trade-off.

  • Five minutes: Add requirements, alternatives, ownership, and evidence.

  • Full review: Walk the flows and boundaries, test failure assumptions, inspect evidence, and record decisions and follow-ups.

Rehearsing the same design at different lengths builds judgment about what matters. It also makes architecture explanations useful to engineers, operators, security reviewers, product owners, and executives without changing the underlying reasoning.

Common Mistakes

  • Answering with a service diagram before stating the concern.

  • Treating every reviewer question as an attack that must be defeated.

  • Raising risks without connecting them to a requirement, owner, or follow-up.

  • Hiding uncertainty instead of converting it into an experiment or review action.

  • Ending with vague agreement and no recorded decision, owner, evidence, or date.

  • Practicing only ideal answers instead of failure and recovery conversations.

If Someone Asks You

What makes a good architecture review conversation?

A good answer is:

It connects the business context to a specific concern, compares realistic options, makes trade-offs and ownership visible, and ends with evidence or a clear follow-up. The participants challenge assumptions without turning the review into a product quiz. Everyone should understand what was decided, why it fits, and how the team will know.

What You Should Remember

Clear architecture conversations are a skill you can practice.

Questions to Check Your Understanding

  1. Which question would expose a hidden ownership gap in your current design?

  2. How would you explain one architecture decision in thirty seconds?

  3. What evidence could cause you to change that decision?

Further Study