Design Starts With Quality Attributes

DabbaGo's engineers are arguing: one group wants to split the app into services, another wants to add a cache, a third wants to rewrite in a faster language. Nobody can win, because nobody has said what "better" means. Features tell you what the system does. Quality attributes tell you how well it must do it, and they are what actually decide the shape of the design.

The rule

Measure the qualities first; then pick the simplest design that meets them.

A quality attribute is a property of the whole system, not a feature. The common ones:

• Performance: how fast it responds under load.
• Availability: how much of the time it works.
• Scalability: how it copes when load grows.
• Security: how well it resists misuse.
• Modifiability: how cheaply it can be changed.
• Cost: what it takes to build and run.

"Fast" and "reliable" are wishes, not requirements. Turn each into a quality attribute scenario, a short, testable sentence with three parts:

1. Stimulus: what happens. 3,000 customers place orders between 12:20 and 12:30.
2. Environment: under what conditions. On a normal weekday, all servers healthy.
3. Measured response: what the system must do, with a number. 95% see a confirmation within 2 seconds; no order is lost.

Now designs can be judged. Load-test the current single server: if it already meets the scenario, the services-versus-cache argument is over, because nothing needs to change.

That is the second half of the rule. Among designs that meet the scenarios, prefer the one with the fewest moving parts. Every extra component, a cache, a queue, another service, is something that can fail, must be monitored, and has to be understood by the next engineer. Simplifying is not laziness; it is removing everything the scenarios do not pay for.

The shortcut

For every design proposal, ask two questions in order: "Which scenario does this fix?" and "Is there a simpler way to fix it?" A proposal that fixes no written scenario is decoration.

The trap is designing for imagined scale: building for a million orders a minute when the real peak is 3,000 in ten minutes. You pay for that complexity every day, and the scale may never arrive.

Drills

Answer fast — trust the rule.

Remember

• Quality attributes such as performance, availability, security and cost drive the design, not the feature list.
• Shortcut: "which scenario does this fix?" then "is there a simpler way?"
• Trap: designing for imagined scale and paying for the complexity every day.