Architecture Reviews: Phrases for Technical Discussions
5 exercises on architecture review phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.