Stakeholders demand strong consistency, sub-100 ms latency, 99.99% availability, and fast delivery of new features — all at once. How do you prioritize conflicting quality attributes and make the trade-offs explicit?

## Step 0 — name the conflicts out loud The four demands are pairwise antagonistic in known ways: | Pair | Mechanism of conflict | |---|---| | Strong consistency ↔ low latency | Coordination costs a round trip; cross-region quorum adds 50–150 ms (PACELC's "else" branch) | | Strong consistency ↔ availability | During a partition you must refuse or diverge (CAP) | | High availability ↔ delivery speed | Most incidents are caused by change; more deploys, more risk | | Low latency ↔ cost | Headroom, caching tiers, more regions, better hardware | | Delivery speed ↔ security/compliance | Reviews, controls, audit gates | | Availability ↔ simplicity | Failover machinery adds its own failure modes (split brain, flapping health checks) | Saying this explicitly reframes the conversation from "do everything" to "choose where to spend", which is the actual deliverable. ## Step 1 — make every demand measurable Each becomes a six-part scenario (source, stimulus, artifact, environment, response, **response measure**). "Strong consistency" must become e.g. *"a seat, once reserved, is never sold twice, even during a 5-minute inter-region partition"*. "Fast delivery" becomes *"a new payment provider is integrated in ≤ 3 person-days touching only the payments module"* and/or DORA metrics (lead time, deploy frequency, change-failure rate, MTTR). Unmeasured demands cannot be traded, only shouted about. ## Step 2 — the utility tree A utility tree (from the SEI's ATAM/QAW practice) is a four-level structure: ``` Utility ├── Availability │ ├── "AZ loss during peak" (H, H) <- (business importance, technical risk) │ └── "Admin console outage" (L, L) ├── Performance │ ├── "Checkout p99 <= 800 ms @ 6k/s" (H, M) │ └── "Report export < 60 s" (M, L) ├── Consistency │ └── "No double-sold seat under partition" (H, H) └── Modifiability └── "New payment provider <= 3 days" (H, M) ``` Each leaf is a concrete scenario with a (importance, difficulty/risk) pair. **Design against the (H,H) leaves first**; the (L,·) leaves are explicitly permitted to be mediocre. The rating must come from stakeholders — product/business owners for importance, engineering for risk. The moment engineers assign business importance themselves, the exercise loses its authority. A useful forcing device: give stakeholders a fixed budget of "high" votes, or ask them to rank rather than rate. If everything is critical, nothing is prioritized. ## Step 3 — evaluate architectures, not opinions (ATAM in miniature) For each top scenario, walk the candidate architecture and classify decisions: - **Sensitivity point** — a decision to which one attribute is highly sensitive (e.g. replication factor → durability). - **Trade-off point** — a decision that is a sensitivity point for *two or more* attributes in opposite directions (e.g. *synchronous* cross-region replication: consistency ↑, RPO ↓, but write latency ↑ and availability ↓). Trade-off points are the architecture's real decision list. - **Risk** — a decision (or absence of one) that endangers a high-priority scenario. - **Non-risk** — a decision that is fine given current assumptions; record the assumption, because it may expire. Then **buy information** where uncertainty is expensive: spike the cross-region write latency with a real prototype, run a partition drill, load-test the fan-out. "Set-based" design — carrying two options until measurement kills one — is cheaper than defending a guess. ## Step 4 — decompose the demand (the move that usually dissolves it) Global "all four" requirements are almost always an artifact of not scoping. Split by: - **Journey / bounded context**: payments strongly consistent; catalogue and feed eventually consistent; analytics best-effort. - **Operation**: writes coordinated, reads served from replicas with bounded staleness or read-your-writes sessions. - **Tier of user**: enterprise tenants get isolated cells and stricter SLOs; free tier gets shared capacity and shed first under overload. - **Time**: strict during business hours or peak season; relaxed otherwise. - **Failure mode**: full functionality normally, defined **degraded mode** during partition/overload (read-only, cached, queued-and-confirm-later). Also look for **business-process escapes**: many consistency demands are really "never embarrass us", and can be met by optimistic reservation plus compensation (overbooking + rebooking, provisional charges, idempotent reconciliation). That converts an expensive technical constraint into a cheap operational one — the highest-leverage move available. ## Step 5 — price it Make the cost curve visible: "99.9% is the current design; 99.99% adds multi-region active-active, doubles infra spend, requires 24/7 on-call and quarterly game days, and slows deploys because every change needs staged rollout. Is that worth $X?" Stakeholders almost never insist once availability is a line item rather than an adjective. The same applies to latency (headroom is idle capacity you are paying for) and to consistency (a round trip per write). ## Step 6 — institutionalize the decision A one-time decision decays. Make it live: - **ADRs** (architecture decision records): context, decision, consequences, **alternatives rejected and why**. The rejected options are the valuable part when someone re-litigates in a year. - **SLOs + error budgets**: the canonical mechanism for the availability ↔ delivery-speed conflict. Budget remaining → ship fast, take risks. Budget burned → freeze features and spend on stability. It removes the argument by pre-agreeing the rule. - **Fitness functions**: automated, continuously running checks for the attributes you claimed — architecture/dependency tests for modifiability, load tests in CI for latency, chaos/partition drills for availability, security scans for the security scenarios. Without them, "we prioritized modifiability" is unverified sentiment. - **Review cadence**: revisit the utility tree when the business changes (new market, new regulation, 10× growth). Priorities are not permanent; assumptions expire. ## Anti-patterns to call out - **Gold-plating the unranked**: five nines on an internal admin tool while checkout has none. - **Averaging the conflict**: choosing a middling design that satisfies no scenario well, instead of being deliberately excellent at the top two and deliberately mediocre elsewhere. - **Architect-decides**: making the value call yourself. Your job is to expose consequences and cost; the business owns the ranking. (Where the business cannot decide, you decide *and write down* the assumed ranking so it can be contradicted.) - **Deciding once, never measuring**: no SLO, no fitness function, so drift is invisible until an incident. - **Ignoring development-time attributes**: teams trade away modifiability and testability silently because no stakeholder names them, then pay for it every sprint. Represent them in the tree explicitly. - **Treating constraints as attributes**: a regulatory requirement is not tradeable; put it in the constraints list and design within it. ## What a strong interview answer sounds like A sentence of framing ("these conflict in known ways, so the deliverable is a ranking, not a promise"), the mechanism (scenarios → utility tree → sensitivity/trade-off points → measured spikes), the decomposition move (per journey/operation), the pricing move (cost curve, error budget), and the durability move (ADR + fitness functions) — ideally illustrated with one real trade-off you made, including what you deliberately let be worse.