Architecture Reviews: Phrases for Technical Discussions
5 exercises on architecture review phrases. Choose the most natural and professional option.
0 / 10 completed
1 / 10
In an architecture review you want to raise a concern about the message fan-out problem. Which phrase is most constructive?
Option A is the complete concern. It names the issue ('fan-out problem'), describes the specific failure mechanism ('message per user'), and quantifies the risk ('high-traffic events could overwhelm the queue'). This gives the team enough information to evaluate the concern rather than just knowing you're worried. 'This approach has a problem' (B) identifies nothing. 'I don't think this will work' (C) is a prediction without reasoning. 'There's an issue with this design' (D) is similarly vague. In architecture reviews, concerns land best when you name the failure mode, the trigger condition, and the consequence — all in one sentence.
2 / 10
You want to probe how the design handles upstream service outages. Which what-if question is most precise?
Option C is the precision what-if. It specifies the failure scenario (upstream service down for 30 seconds), names the thing at risk (the order), and offers two concrete hypotheses (lost vs retry mechanism) — which forces a specific answer rather than a generic one. 'What if it breaks?' (A) is too abstract to drive a useful answer. 'What happens if it fails?' (B) is slightly better but 'it' and 'fails' are both vague. 'How do we handle failures?' (D) is a good question in general but too broad for a specific architecture decision. Great probing questions name the specific failure, the affected resource, and the expected outcome.
3 / 10
You want to check whether the design accounts for partial write failures during a data migration. Which question is best?
Option B is collaborative and specific. 'Have we mapped out the failure modes' is a group question (not a challenge to the individual), and 'I'm particularly curious about partial writes during the migration' narrows the topic to the highest-risk scenario. 'Did you think about failures?' (A) sounds like a challenge to the designer's thoroughness. 'What if something goes wrong?' (C) is so broad it could mean anything. 'Failure modes should be considered' (D) is a principle stated as a reminder, not a genuine probe. Architecture probes work best as 'we' questions that name the specific risk area you're concerned about.
4 / 10
This design optimises for write throughput but at the cost of read latency. How do you name this trade-off clearly?
Option D is the complete trade-off statement. It names what is being optimised (write throughput), names the cost (read latency), accepts the trade-off conditionally ('fine if workload is write-heavy'), and flags the assumption that needs confirming. 'This has trade-offs' (A) is universally true and says nothing. 'There are pros and cons to this' (B) is the same vagueness dressed differently. 'This design is not perfect' (C) is true of all designs and even less useful. Naming a trade-off means naming both sides and the condition under which the trade-off is acceptable — that's what drives a useful architecture discussion.
5 / 10
You want to validate gRPC latency under load before the team commits to the architecture. Which phrase makes this ask most convincingly?
Option A is the complete PoC ask. It names the action (proof of concept), explains when it should precede (before we commit), and most importantly specifies the exact hypothesis to test (gRPC latency under load). Without that hypothesis, a PoC might test the wrong thing. 'Can we test this first?' (B) is reasonable but gives no scope. 'Let's try it before deciding' (C) is similar — no scope, no success criterion. 'A PoC would help us decide' (D) states a general principle without committing to an action. Effective PoC requests name what you're testing and what passing looks like.
6 / 10
Alex from the backend team is proposing a new microservice to handle user authentication. During a code review, you notice the service doesn't explicitly handle rate limiting. Which phrase best expresses your concern while remaining collaborative?
The key here is to frame the concern constructively. Option 1 directly points out a lack of documentation (which might be a symptom) but doesn't express the core issue – potential abuse and scaling issues. Option 2 uses 'I'm concerned' to take ownership and proposes a discussion, while options 3 and 4 are dismissive or inappropriate for a code review scenario. Rate limiting is crucial for microservice resilience.
7 / 10
You're drafting the description for a pull request that introduces a change to the payment processing logic. A stakeholder asks you to clarify how the system handles failed transactions. Which of the following phrases is most effective in prompting further discussion?
Option 2 is a red herring; it doesn't solicit any further information. Options 1 and 3 are too vague or directly state assumptions that may not be true. Option 4 focuses on performance instead of error handling. Asking about retry mechanisms and fallback strategies is the most proactive way to understand how the system deals with failures, prompting a deeper conversation.
8 / 10
During a standup meeting, you're discussing progress on a new feature. A teammate mentions they've implemented a complex caching strategy. You want to ensure the design considers potential cache invalidation issues. Which question would best guide that discussion?
Option 3 directly addresses a critical aspect of caching – performance. While the other options are relevant, they don't specifically probe the core concern of invalidation and its potential cascading effects. Cache invalidation problems can lead to significant inconsistencies if not handled properly.
9 / 10
You receive an API response indicating a high latency for a specific endpoint during load testing. The documentation states the expected response time is under 200ms. What phrase would you use in a Slack message to alert the team and request investigation?
Option 1 is completely incorrect and ignores the observed issue. Option 2 immediately acknowledges the problem and requests investigation. Options 3 and 4 are dismissive or shift responsibility without action. A clear statement of the observation and a request for help is crucial in Slack communication.
10 / 10
You're reviewing a design that prioritizes high throughput but with increased latency. The architect explains this trade-off. Which phrase best summarizes your understanding and confirms alignment?
Option 3 acknowledges the trade-off while highlighting the need to explore mitigation strategies. It demonstrates critical thinking and doesn't simply accept the compromise passively. Options 1 and 4 are either too accepting or overly negative without proposing solutions. Option 2 pushes back unnecessarily.
What will I practise in "Architecture Reviews: Phrases for Technical Discussions"?
This module focuses on Phrasebook — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Phrasebook exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around phrasebook — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Phrasebook exercises?
See the Phrasebook hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.