English for Architecture Reviews: How to Give and Receive Design Feedback

Architecture reviews are collaborative exercises, but they can easily become adversarial if participants lack the vocabulary and social language to give and receive feedback constructively. This guide covers the technical vocabulary reviewers use, the phrases for delivering criticism professionally, and the responses that keep a review productive when your design is challenged.

Architecture Review Vocabulary

Scalability — the ability of a system to handle increased load by adding resources. Distinguish between vertical scaling (more powerful hardware) and horizontal scaling (more instances). “My main concern with this design is horizontal scalability — the shared session cache becomes a bottleneck as we add more application nodes.”

Trade-off — a situation where gaining one benefit requires accepting a drawback. Good architecture review vocabulary always pairs a benefit with its cost. “The trade-off here is between consistency and availability; this design chooses consistency, which means some requests will fail during a network partition.”

Coupling — the degree of dependency between components. High coupling means a change in one component requires changes in others. “The direct database call from Service A to Service B’s schema creates tight coupling — it means both services must be deployed together whenever the schema changes.”

Cohesion — the degree to which elements within a single component belong together logically. High cohesion is desirable. “The UserService has low cohesion — it handles authentication, profile management, and notification preferences, which are three distinct concerns that should probably be split.”

Bottleneck — a component that limits the throughput or performance of the entire system. “The synchronous call to the PDF generation service is a bottleneck — it can take up to 8 seconds, which blocks the entire request thread.”

Single point of failure (SPOF) — a component whose failure brings down the entire system. “The current design has a single point of failure in the message broker; if it goes down, all asynchronous jobs stop processing.”

Blast radius — the scope of impact if a component fails. “By separating the notification service into its own deployment, we reduce the blast radius of a failure — a crash in notifications won’t affect order processing.”

Idempotency — the property of an operation that can be safely repeated without changing the result beyond the first execution. Critical for retry logic. “Before we approve the retry strategy, we need to confirm that the downstream endpoint is idempotent; otherwise, retries could create duplicate orders.”

Eventual consistency — a consistency model where, given sufficient time without new updates, all replicas of a dataset will converge to the same value. “This design accepts eventual consistency for the inventory count, which is acceptable for display purposes but would need a stronger consistency guarantee at the point of purchase.”

How to Give Constructive Criticism on Designs

The goal of an architecture review is to improve the design, not to demonstrate your knowledge. Frame feedback around outcomes, not deficiencies.

Raising a concern (without attacking):

• “I want to flag a potential concern with the caching strategy — if the cache and the database are briefly out of sync, the user could see stale pricing data at checkout. Is that an acceptable risk?”
• “I am not sure the current design handles the failure scenario where [X happens]. How does the system behave in that case?”
• “One thing I would push back on slightly is the choice of X — can you help me understand the reasoning? I want to make sure I am not missing context.”

Suggesting an alternative:

• “One option worth considering would be [X], because it avoids the coupling issue I raised — though I recognise there are trade-offs there too.”
• “An alternative approach that some teams use for this problem is [Y]. It may not be the right fit here, but it is worth having in mind.”

Acknowledging what works:

• “The event-driven approach here is well-suited to the eventual consistency requirement — that part of the design is solid.”
• “I think the decision to use a separate read model is the right one; it cleanly separates the read and write concerns.”

How to Respond to Concerns

Receiving criticism professionally is as important as giving it. These responses keep the review constructive.

Acknowledging a valid concern:

• “That is a fair point — I had not fully thought through the retry scenario. Let me revisit that section.”
• “You are right that the tight coupling here is a problem. I think we can address it by [X].”
• “That is a good catch. I will add a note to the design doc and we can discuss the mitigation in the follow-up.”

Defending a decision with reasons:

• “We did consider that approach, but we ruled it out because [specific reason]. Does that address your concern, or do you think the trade-off still does not work?”
• “The reason we chose X over Y was [explanation]. I am open to revisiting it if you think the trade-off is wrong.”

Deferring gracefully:

• “That is a good challenge and I want to give it a proper answer — can I take it as an action item and follow up by end of week?”
• “I do not have enough data to answer that confidently right now. Let me pull the numbers and come back to you.”

Example Architecture Review Phrases in Context

1. “My main concern with this design is the tight coupling between the order service and the inventory service — a schema change in either one will require coordinated deployments, which increases release risk significantly.”

2. “The blast radius of a failure in the proposed shared configuration service is quite large; if it becomes unavailable, every dependent service would fail to start. I would recommend making configuration loading fault-tolerant by caching the last known good values locally.”

3. “That is a fair challenge on the eventual consistency model — you are right that a stale read at checkout could cause an oversell. We should add an explicit consistency requirement to the purchase flow and document that eventual consistency is acceptable only for the product listing page.”

4. “I want to flag the single point of failure in the current message broker setup; before this goes to production, I would like to see a high-availability configuration or a documented recovery runbook with a tested RTO.”

5. “You are right that the bottleneck I identified is a real problem, but I think we can address it without a full redesign — moving the PDF generation to an asynchronous job and returning a job ID immediately would eliminate the blocking behaviour.”