Trade-off Analysis
Making the costs of an architectural choice explicit and comparable, rather than presenting a recommendation as if it were free.
Every architecture is a set of trades. The mark of a weak design document is that it lists benefits; the mark of a strong one is that it names what was given up and why that was acceptable here.
The method is unglamorous and reliable: identify the two or three quality attributes actually in tension for this decision, state each option's effect on each, quantify where a number is available, and state the condition under which you would choose differently. That last clause is what turns a decision into something reviewable later.
It is also what senior interviewers listen for. "Microservices" is not an answer. "Microservices, accepting eventual consistency across these two boundaries and a distributed tracing dependency we do not currently have, because these three teams need independent release cadence" is.