An engineer you mentor proposes a design that will work but is not the one you would choose: a single queue with a database-backed dedupe table where you would have used the broker's own idempotent producer. They have thought it through. You are reviewing it. What should you do?

What is actually being decided

Not the design. The design works, so the decision is about who gets to be the author of a judgement call, and what the engineer learns either way. Overruling a workable design teaches that reasoning is performed for the reviewer's approval. Approving it with the boundary written down teaches the thing you actually want to transfer: that a decision is judged by the conditions under which it stops being right.

The useful test is two questions. How reversible is it, and how large is the blast radius? A database dedupe table is reversible in days and confined to one service. Choose your own preference only when reversal is expensive or failure escapes the team — a public API shape, a data model many services read, a security boundary, anything that writes data you will still have in three years.

The condition to write down

This is the part that makes approval a teaching act rather than an abdication. Something concrete and falsifiable: "Revisit if the dedupe table exceeds 50 million rows, or if p99 enqueue latency passes 40 ms, or the first time we need this in a second service." A condition with a number is a trigger; "revisit if it becomes a problem" is not.

Why the other options fail

• Ask them to change it. You get the design you wanted and pay for it twice: their reasoning was discarded, and the next proposal will be an attempt to guess your preference. Reserve this for the irreversible cases, and when you use it, say plainly that it is your call and why.
• Approve silently and fix it later. The worst option. It hides the disagreement, does the work twice, and when the refactor lands the engineer learns that review is theatre.
• Escalate to their manager. A design disagreement between an engineer and a reviewer is the normal work, not a conflict. Escalating it costs you standing and tells the engineer their judgement is a management matter.

What a strong answer adds

Say your preference out loud without attaching a requirement to it. "I would have used the broker's idempotent producer, because the dedupe state stays with the broker and there is no table to grow. I do not think that is worth changing here." The engineer gets the mechanism, keeps the authorship, and can decide for themselves next time — which is the outcome you are hired for.

When this is the wrong answer

When the cost of being wrong is not the engineer's to carry. A design that is reversible for the team and irreversible for the company is not a mentoring opportunity: schema on a shared table, a message format other teams consume, retention of personal data, an external contract. There, be direct, own the decision, and explain the asymmetry, because the lesson in those cases is that some choices are made at a different altitude.