Design review is seeing what isn’t there

Most code review trains you to spot what’s present and wrong — a bad query, a missing escape. Design review is harder: the defect is usually something absent. No timeout. No idempotency key. No version on the event. No ownership check at the boundary. The diagram is tidy; the failure mode is invisible until you go looking for it on purpose.

That makes it a perceptual skill, not a knowledge one. You already know what a circuit breaker is. The hard part is noticing it’s missing in the third box of an architecture doc, fast, without flagging the ten sound decisions around it.

Ship / Flag / Escalate — for designs

• Ship — the design is sound for its stated requirements; the "problem" you’re tempted to raise is a legitimate tradeoff.
• Flag — a definite design defect: a missing guarantee that will bite (data divergence, an outage amplifier, an unbounded resource).
• Escalate — correctness depends on a fact you can’t see here (an SLO, a scale target, an unstated requirement). Route it to a human before judging.

Calibration: don’t over-engineer the verdict

The over-flagging reviewer is as dangerous as the rubber-stamp. A modular monolith for a two-person team is not a bug because it isn’t microservices. A synchronous call is not a bug because it isn’t an event. Retries are not a bug — unbounded retries are. Scored on two axes at once:

• Catch rate — of the genuinely flawed designs, how many did you stop?
• False-alarm rate — of the sound designs, how many did you wrongly block?

Four warm-up cards below. Two are safe — a deliberately-simple design and a sound stateless service. Don’t flag them for being modest.