Practice vocabulary for architecture review meetings: presenting architecture, handling technical challenges, and discussing failure modes.
0 / 5 completed
1 / 5
During an architecture review, a reviewer asks about what happens when the payment service goes down. Which phrasing names the concept most precisely?
'Failure mode' is the precise architectural term for the way a system fails — how it behaves under a failure condition. 'What's the failure mode if X goes down?' is standard architecture review vocabulary: it asks about the specific behaviour, not just the recovery plan. 'Fallback' refers to an alternative mechanism activated during failure — a valid follow-up question but not the same as the failure mode itself. 'Recovery' refers to how the system restores state after failure. 'Fault' is the underlying defect, not the observable behaviour. In reviews, identifying failure modes precedes designing mitigations.
2 / 5
You are presenting the architecture and want to guide reviewers through the data flow diagram. Which phrase is most natural?
'Walk you through' is the most natural and common phrase for guiding an audience through a technical diagram, process, or architecture: 'Let me walk you through the data flow', 'I'll walk you through the architecture', 'she walked the reviewers through the deployment sequence'. 'Take you through' is also widely used and acceptable. 'Show you through' is non-standard in this context. 'Guide you through' is correct but more formal and less frequent in engineering meetings. 'Walk through' is the default in architecture presentations.
3 / 5
A reviewer wants more detail on a design decision. Which question uses the correct vocabulary?
'Design trade-offs' is the most precise term in the context of architecture reviews — it refers to the conscious choices made between competing design properties (e.g. consistency vs. availability, latency vs. throughput, simplicity vs. flexibility). 'Architecture trade-offs' is also widely used. 'Performance trade-offs' is narrower — it refers specifically to performance properties and may not cover correctness, operability, or cost trade-offs. 'System trade-offs' is too vague. In architecture reviews, 'can you elaborate on X' is the standard phrase for asking a presenter to expand on a specific point.
4 / 5
A reviewer asks how the new caching service fits with the existing infrastructure. Which verb is most precise?
'Integrate' is the standard technical verb for connecting systems in a way that allows them to function together as part of a larger whole. 'How does this integrate with our existing infrastructure?' is the correct vocabulary for architecture reviews — it implies a defined interface, data exchange, and operational compatibility. 'Connect' is more physical or network-focused. 'Work with' is informal. 'Fit with' is vague. In architecture review meetings, integration questions cover APIs, authentication, data formats, observability, and operational dependencies.
5 / 5
During the review, you have a concern that must be resolved before the architecture can be approved. How do you classify your concern?
'Blocking concern' is the precise review vocabulary for a concern that prevents approval until resolved. 'I have a blocking concern about X' signals that the review outcome is 'needs revision' — not 'approved'. This is distinct from a 'non-blocking concern' (noted, addressed later) and an 'action item' (tracked but not approval-gating). 'Technical concern' and 'critical concern' are vague — they do not communicate the approval impact. In architecture reviews, the blocking/non-blocking distinction is the most important vocabulary for signalling review status and driving clear outcomes.