Two quality attributes are in direct conflict and both stakeholders say theirs is non-negotiable. How do you resolve that?

Adjectives cannot conflict, numbers can

While both positions are stated as adjectives, the conflict is unresolvable, because "it must be secure" and "it must be fast" are not in tension with each other in any way you can reason about. Nothing can be traded until both sides are expressed as something measurable, and getting them there is most of the work.

The form that does this reliably is a scenario: a source of stimulus, the stimulus itself, the state of the system when it arrives, and the response you require with a number on it. "When a user submits the checkout form at peak hour, the confirmation is rendered within 500 milliseconds at the ninety-ninth percentile." "When any administrative action is taken on a customer record, an immutable audit entry exists before the action becomes visible, with no path that skips it." Now the two statements are about the same event, and you can see exactly where they collide: the audit write is synchronous and it is inside the latency budget.

That reframing does something politically useful as well as technically. It moves the discussion from whose value is more important to what the system does in one specific situation, and it means the stakeholders are arguing about a claim you can test rather than about a principle neither of them will concede.

Show the curve, not the two ends

A conflict presented as two options invites a winner and a loser, and the loser will relitigate it. A conflict presented as a set of intermediate designs invites a choice. So enumerate the middle, because the middle is usually where the answer is and it is where architecture earns its keep.

For the audit-versus-latency case the intermediate positions are real and each has a distinct shape. You can write the audit entry synchronously and accept the latency cost, which is the security stakeholder's position. You can write it asynchronously and accept a window in which an action is visible before it is durably recorded, which is the performance stakeholder's position with its cost made explicit. Between them, you can write to a durable local log synchronously and ship it asynchronously, which bounds the loss to the failure of one machine rather than to the failure of a queue. You can make only the subset of actions that genuinely require it synchronous, which converts a system-wide trade-off into a classification exercise. Or you can spend money on the underlying mechanism until the cost falls below the budget, which is the option people forget because it appears on a different budget line.

Option	Latency effect	Audit gap	What it costs elsewhere
Synchronous audit for every action	Full write cost inside every request	None	Throughput, and coupling to the audit store's availability
Asynchronous audit	Negligible	Actions visible before recorded, bounded by queue lag	Auditability during an incident, which is when it matters
Synchronous local durable write, shipped later	One local write	Loss only on loss of that host	Operational complexity of shipping and reconciling
Synchronous only for classified actions	Cost on a minority of requests	None for the classified set	An ongoing classification decision somebody must own
Faster audit path, provisioned harder	Reduced	None	Money, and it moves the problem to a cost conversation

The point of the table is not the recommendation. It is that once the options are laid out this way, the stakeholders can usually see which of them they were actually arguing for, and in a meaningful number of cases the conflict dissolves because both positions were compatible with row three or row four all along.

Where the conflict is genuine, decide by consequence ownership

Some conflicts do not dissolve. When they do not, the mistake is to resolve them yourself with a compromise that gives each side less than they asked for, because a silent split of the difference produces a system that satisfies neither requirement and has no owner who will defend it. It also hides the decision, so nobody knows a sacrifice was made.

The move instead is to find the single person who owns both consequences. Two stakeholders each protecting one attribute have no incentive to yield; someone above both of them owns the outcome where either failure lands, and that is the person with standing to choose. What they need from you is short and specific: the two scenarios with their numbers, the option set with its costs, your recommendation, and a plain statement of what the organisation is accepting under the recommendation. "We are accepting that in the event of a queue outage there is a window of up to two minutes in which administrative actions are visible but not yet recorded" is a sentence a director can decide about. "We are balancing security and performance" is not.

Occasionally the answer that comes back is that both are truly required, and then the conflict has become a funding question rather than an architecture question. That is a legitimate resolution and you should be willing to say it out loud: this can be had, and here is what it costs, and if that is not available then one of the two requirements is not a requirement.

Write down the attribute you sacrificed

The decision record has to name the loser explicitly, with the cost quantified and the reason stated. This is the part that gets skipped, because records are written to justify the choice and describing what you gave up reads as weakness. It is the opposite: it is the only thing that makes the decision reviewable, and it protects the next team from re-running the entire argument from ignorance.

Then attach a revisit trigger, which is what stops the sacrifice from becoming permanent by accident. A good trigger is observable rather than calendar-based: when the audit gap exceeds a stated duration for more than a stated number of days, when the latency budget is being met with margin to spare, when the volume of classified actions crosses a threshold. A date-based review works too but tends to be missed. The purpose either way is that the sacrificed attribute has a route back into the conversation that does not depend on somebody remembering an argument from two years ago.

The conflict that was never between the attributes

Before accepting any of this, check whether the conflict is between two quality attributes at all, because frequently it is between two people's understanding of the same requirement, and it is resolved by measurement rather than by trade-off. One party says the system must be highly available and means that a specific business process must not stop; the other hears that every component needs redundancy. One says it must be fast and means a particular screen feels slow; the other budgets the entire request path. Establishing what each side would accept as evidence of success frequently reveals there is no conflict, only two unquantified statements pointed at each other.

The related trap is optimising an attribute nobody measures. An organisation will happily accept a substantial cost for availability while having no instrumentation that would tell it whether availability improved, which means the trade-off was decided in favour of something unverifiable. If neither attribute is currently measured, the first deliverable is not a design; it is the measurement, because you cannot trade what you cannot see and the conversation will otherwise repeat every quarter with different adjectives.

Convert both positions into scenarios with numbers, then lay out the intermediate designs — a surprising share of these conflicts dissolve once both sides can see a row that satisfies them. Where the conflict is real, escalate to whoever owns both consequences and record the sacrificed attribute with a trigger for revisiting it.