Why Quality Attributes Matter

An architectural driver is a requirement that shapes the architecture far more than an ordinary requirement does, so that getting it wrong would force a different structure. Drivers come from five sources: the top quality-attribute scenarios, the primary functions, constraints, business goals and architectural concerns such as thin team skills or a legacy migration. At ShopNow, checkout p95 of 800 ms at 1,500 requests per second and 99.95% availability during sales are drivers; the layout of the order-history page is not. A good driver list is short, five to ten items, prioritised, measurable and owned by a stakeholder, and every major decision in an ADR should trace back to one of them.

A constraint is a decision that has already been made, by a regulator, the enterprise or the business, and the architecture must honour it; a quality requirement is a measurable target that the architecture optimises and may trade against other targets. Keeping customer data in India under RBI and DPDP rules is a constraint: nobody on the project can negotiate it, so the DR region moves to Hyderabad instead of Singapore. Checkout p95 under 800 ms is a quality requirement: it can be prioritised, relaxed on non-critical paths or balanced against cost. Mixing them up is costly, because treating mere preferences as constraints closes good options far too early.

Quality attributes force trade-offs because every tactic that improves one quality consumes something another quality needs: CPU, latency budget, money, simplicity or consistency. Caching product prices for 60 seconds improves performance and database load but costs freshness. Running Multi-AZ active-active improves availability but adds roughly 70% to infrastructure cost and more operational complexity. Encrypting fields with per-field keys strengthens security but adds latency and key management. Because the qualities compete for the same finite resources, you cannot maximise all of them at once. The architect's job is not to avoid trade-offs but to choose them deliberately, per path, against prioritised drivers, and to record them in ADRs.

A sensitivity point, in ATAM terms, is a design decision or parameter to which one quality attribute responds strongly, so a small change in it produces a large change in that quality. A cache TTL is the classic example: moving from 30 to 300 seconds dramatically changes data freshness. A HikariCP pool size is another: throughput rises until about 20 connections and then database CPU becomes the limit. Identifying sensitivity points tells you which settings deserve load tests, monitoring and change control. When the same decision affects two qualities in opposite directions, it becomes a trade-off point, which needs explicit agreement from stakeholders rather than quiet tuning by one team.

Replication mode for a payments database is a clear trade-off point. Synchronous replication across regions gives an RPO of zero, because no committed transaction can be lost, but every write waits for the remote acknowledgement, adding roughly 30 ms of write latency in ShopNow's case. Asynchronous replication keeps writes fast but accepts seconds of data loss if a region fails. Another example is Kafka with acks=all and min.insync.replicas of 2: durability improves, but p99 publish latency rises by around 4 ms per event. The right answer depends on the drivers; for payments, durability usually wins, whereas for clickstream events lower latency and cost matter more.

Multiply the revenue lost per hour of downtime by the expected hours of downtime per year, then add SLA credits, regulatory penalties, recovery effort and a reputational allowance, and compare the total with the cost of the tactic. Use different hourly rates for peak and normal periods, because an hour on a sale day can cost ten times more. At ShopNow a single-AZ database costs ₹40 lakh a year but risks about eight hours of downtime, worth roughly ₹4.3 crore; Multi-AZ costs ₹75 lakh with about one hour expected, worth ₹0.5 crore. The inputs come from finance, incident history and cloud SLAs, and should be revalidated every quarter.

Typically five to ten, prioritised. Drivers exist to focus design effort and to settle conflicts, and a list of thirty requirements does neither: everything looks important, so nothing guides a decision. Start from the full scenario catalogue, rank each scenario by business importance and technical risk in a utility tree, and promote only the high-high items plus the hard constraints and key functions. The rest still matter, but they are handled by standard platform practices rather than by the structure of the architecture. Review the list every quarter and before big events, because a new regulation or growth target can promote a scenario into the driver set.

First, check that it really is a constraint: ask who imposed it and whether it can change, because many so-called constraints are preferences. If it is genuine, quantify what it costs the quality in business terms, for example extra latency or lower availability expressed in rupees per year, and take that evidence to the constraint's owner. They may relax it, fund a mitigation or accept the consequence. If it stands, design the best option within it, such as in-country DR in Hyderabad when data must stay in India, and record the constraint, the impact and the decision-maker in an ADR, so the consequence stays visible later.

Show the risk-adjusted cost rather than the price tag. Put each option's annual cost next to its expected losses, downtime hours multiplied by revenue per hour, plus penalties and incident effort, and add any revenue it gains, such as conversion from lower latency. At ShopNow, Multi-AZ adds ₹35 lakh a year but avoids about ₹3.4 crore of expected downtime cost, so the expensive option is cheaper overall. Tie the argument to a business goal the sponsor already owns, use finance's numbers rather than your own, and present it as a one-page decision brief. Stakeholders approve returns on investment; they rarely approve architecture for its own sake.

Quality attributes are structural: they come from how components, data and interactions are arranged, not from a few lines of code. A missing quality found late therefore means changing structure that other work has been built on, often along with data, contracts and operational processes. ShopNow's missing payment idempotency would have cost two days to fix in design review and three weeks after a load test, including refactoring and data fixes. Found in production, it meant double charges, refunds, an RBI complaint and two months of work. This is why architects state quality scenarios early, test them with prototypes and load tests, and review designs before building.