The system launched after a 90-minute review. Everyone approved. Six months later it failed in exactly the way nobody asked about — the cache had no fallback, and the on-call engineer had no metric to tell them why requests were timing out.
Why Reviews Fail
Most reviews ask: "Is this design good?"
That is not a reviewable question. The database expert asks about schema design. The frontend lead asks about API contracts. Nobody asks what happens when the message queue backs up at 2 AM, because that requires knowing where the queue sits in the request path — and nobody drew that on the diagram.
The gaps between expertise zones are where production failures live.
Seven Questions That Make a Review Structural
Replace "is this good?" with seven specific questions, applied in order:
Q1 — Scale: What specific component hits its limit first at 10x load?
Q2 — Failure: What happens to users when [each major component] is unavailable?
Q3 — State: Where does state live? Can it replicate? What if replicas diverge?
Q4 — Latency: What is the slowest path through the system in milliseconds?
Q5 — Evolution: What breaks if requirements change in six months?
Q6 — Security: What data is exposed if the auth boundary is breached?
Q7 — Observe: What exact metric or log line fires when this system degrades?
Q7 is not "do you have monitoring?" It is "name the specific alert, and what threshold triggers it." If the presenter cannot answer, the system is not observable — regardless of how many dashboards exist.
These questions work because they are concrete. "Is this a good design?" requires a judgment. "What happens to user checkouts when the inventory service is unavailable?" requires an answer.
Senior Review vs Staff Review
A senior engineer evaluates: reads the design, checks whether the solution is correct, approves if it seems reasonable. This catches obvious mistakes. It misses structural gaps.
Senior engineer: Is this design correct? → catches bugs
Staff engineer: What has this design not answered? → catches failure modes
A staff engineer interrogates assumptions. They look for unstated guarantees — things consumers will assume but the system never promised. A design can satisfy every stated requirement and still fail because the requirements themselves were incomplete.
The difference is method, not seniority. Structured questions surface what personal expertise misses.
The One Question Before Approval
Before signing off on any design, ask: "What does this system not guarantee — and does every consumer know it?"
Every system has limits. The design document describes what it does. The review must surface what it does not. If a consumer assumes a guarantee the system never made, the failure is not a bug. It is an unwritten contract — and unwritten contracts break in production.
If you cannot answer that question for every interface the system exposes, the review is not done.
Concept: Architecture review as structured interrogation
Tradeoff: AT9 — a thorough review takes time; a fast approval feels productive; the cost appears in production six months later
Failure Mode: FM11 — the system fails in a way nobody monitored because nobody asked what it did not promise
Signal: When an approval takes under 30 minutes and nobody asked Q7
Series: Book 6, Ch 9