Software architecture · Level 1: Architecture characteristics · Module 05 of 46

Defining and measuring characteristics

"The system must be fast and scalable" can't be designed for, tested or argued about, because nobody agrees what it means. A characteristic becomes useful only when it has a definition you can measure: "checkout answers in under 300 ms for 99% of requests, with 5,000 buyers at once". This module turns the common characteristics into measures, and shows two pairs that people constantly mix up, with very different designs behind them.

1. The idea

A health check. "I want to be healthy" is a wish. A doctor turns it into measures: blood pressure under 120/80, resting heart rate, cholesterol. Some are taken in a minute (operational), some describe your build (structural), some track habits over months (process). Once there's a number, you can see progress, and argue about whether a treatment worked.

Architecture characteristics get the same treatment. There are three kinds of measure:

Kind	What it measures	Examples
Operational	The running system	Response time at the 95th and 99th percentile, requests per second, availability %, time to scale out
Structural	The code and its shape	Cyclomatic complexity, coupling between components (Module 07), size of the test suite, dependency cycles
Process	How the team changes it	Deployment frequency, lead time from commit to production, change failure rate, time to restore service

Two pairs that get confused

Performance vs responsiveness

Performance is how long the whole piece of work takes. Responsiveness is how quickly the user gets a useful reply. An order that takes 2.4 seconds to process can still feel instant if the user hears "order received" in 80 ms and the rest happens in the background.

Scalability vs elasticity

Scalability is handling more load as it grows steadily, with response times staying in target. Elasticity is handling a sudden burst: how fast capacity can grow (and shrink) when load jumps in seconds. A system can scale to millions of users over a year and still fall over when 100,000 arrive in one minute.

Two more that need precise definitions: testability (how completely and quickly the system can be tested automatically: low complexity, isolated components, a suite that runs in minutes) and deployability (how often, how safely and with how little ceremony a change reaches production).

2. How it works

Responsiveness without changing performance

The same order, the same four steps, the same 2.4 seconds of work. Watch the clock in the customer's box.

Measuring scalability: find the knee

Scalability is measured with a load test: increase the number of users step by step and watch response time. It stays flat, then suddenly bends upwards. That bend, the knee, is your real capacity, and the part that saturates first is your bottleneck.

3. Try it yourself

Scalability or elasticity?

An autoscaler adds servers (500 requests a second each) when it sees load rise. Choose the load shape, how long a new server takes to be ready, and how much spare capacity to keep. Red area = requests turned away. Then try scaling up on a schedule, before the sale starts.

Simulation of 30 minutes in 10-second steps. The autoscaler checks every 30 seconds and asks for enough servers to carry the current load plus the spare capacity; new servers start serving after the chosen delay. Steady growth goes from 1,000 to 4,000 requests a second over 30 minutes; the sale jumps from 1,000 to 12,000 within a minute at 10:05.

4. Trade-offs

Precise targets vs flexibility

A precise target ("p99 under 300 ms") can be tested and enforced, but it's a commitment that costs money to keep. Set targets only for the top characteristics, and leave the rest as guidelines.

Spare capacity vs cost

Headroom absorbs steady growth cheaply. It does almost nothing for a burst, because it's proportional to today's load, not tomorrow's spike. For known bursts, schedule capacity; for unknown ones, make scaling itself fast.

Responsiveness vs simplicity

Replying early and finishing in the background makes the system feel fast, but the user can see "received" for an order that later fails. That needs status pages, notifications and compensation (Module 24).

Quantitative vs qualitative

Measurements need a running system. Before one exists, compare options qualitatively (ratings, past experience, prototypes), then confirm with numbers as soon as you can build something to measure.

5. In real projects

Use percentiles, not averages. An average of 120 ms can hide 2% of users waiting 4 seconds. Targets are usually set at the 95th or 99th percentile.

Elasticity is a property of the whole chain. Servers that start in 30 seconds don't help if the database connection pool, a downstream service or a licence limit can't grow with them. Load-test the burst, not just the steady state.

Process measures predict structural health. The four delivery measures popularised by the DORA research (deployment frequency, lead time for changes, change failure rate, time to restore) are a practical way to measure deployability and, indirectly, testability and modularity.

Qualitative first, quantitative later. When choosing an architecture style, nobody can measure the options yet. Rate them on the top characteristics (later modules give a rating table for each style), choose, then turn each top characteristic into a measure that runs automatically (Module 26).

Quality attribute scenarios: turning an "-ility" into a testable sentence

"The system must be highly available" can't be tested. The Software Engineering Institute's quality attribute scenario forces six parts, and the last one makes it measurable:

Part	Question	Example: availability	Example: modifiability
Source	Who or what causes it?	Cloud provider	Product team
Stimulus	What happens?	One availability zone goes offline	Asks for a new payment method
Environment	Under what conditions?	Peak evening traffic	Normal development
Artefact	What part is affected?	Checkout service and its database	Payment module
Response	What should the system do?	Fail over to the other zones; no orders lost	The change is made without touching checkout rules
Response measure	How do we know it worked?	Checkout errors back under 0.1% within 60 seconds	Done in 3 developer-days, one module changed

Write one or two scenarios for each top characteristic. They become acceptance criteria, load-test and chaos-test plans, and fitness functions (Module 26), and they are the raw material of an ATAM evaluation (Module 29).

Say it in the interview

Two-sentence answers

"Scalability vs elasticity?" Scalability is keeping response times in target as load grows steadily; elasticity is how quickly capacity follows a sudden burst. Headroom handles growth; bursts need fast scaling or scheduled capacity.
"Performance vs responsiveness?" Performance is how long the work takes; responsiveness is how soon the user gets a useful reply. I can improve responsiveness by acknowledging early and finishing asynchronously, without making the work itself faster.
"How would you measure deployability?" Deployment frequency, lead time, change failure rate and time to restore, plus how many manual steps a release needs.

Red flags interviewers notice

"It needs to be fast" with no number and no percentile.
Answering a burst requirement with "add autoscaling" and no mention of how long scaling takes.
Using code coverage alone as the measure of testability.

6. Remember it

Memory hook: "No number, no characteristic"Every top characteristic gets a measure, a percentile or a rate, and a condition.

How this hook works: what "no number, no characteristic" means

What the slogan means, phrase by phrase

"No number": Without a measure, "fast" or "scalable" means something different to everyone in the room.
"no characteristic": It can't guide a decision, be tested, or tell you when you've succeeded.

Why this picture fits: like a doctor's measures, a number turns a wish into something you can design for and check.

The story → the concept

The health check	The architecture
Blood pressure, heart rate	Operational measures (p99, throughput)
Height, build, bone density	Structural measures (complexity, coupling)
Exercise and sleep habits	Process measures (deploy frequency, lead time)

The trap it saves you from

Arguing for weeks about whether the system is "scalable enough" when nobody wrote down what enough means.

7. Common mistakes

Headroom for a burstKeeping 50% spare capacity barely helps when load multiplies twelvefold in a minute. Try it in the lab: the red area hardly shrinks.

Averages as targetsAn average response time hides the slow tail that real users feel. Use p95 or p99.

Measuring only the serversCapacity is set by the slowest part of the chain: often the database, a connection pool or a third party.

Coverage as testabilityHigh coverage of untested assertions proves nothing. Look at complexity, isolation and how long the suite takes too.

8. Design exercise (30 minutes)

Write the measures (10 min). For your top three characteristics from Module 04, write one measure each: what, which percentile or rate, and under what load.
Find the knee (10 min). Sketch how you'd load-test your system: what you'd increase, what you'd watch, and which part you expect to saturate first.
Plan for the burst (10 min). If your system has a known peak (a sale, a broadcast, month-end), write how capacity will be there in time: scheduled, fast scaling, or queueing the excess.

9. Self-check quiz

Load jumps from 1,000 to 12,000 requests a second within a minute. Which characteristic is tested?

The speed of the change, not its size, is the challenge.

Which part of a quality attribute scenario makes it testable?

"Errors under 0.1% within 60 seconds" can be checked; "recovers quickly" can't.

The user sees "order received" in 80 ms; the order finishes processing 2.4 seconds later. Which improved?

The work still takes 2.4 s; the user just doesn't wait for it.

A sale starts at a known time and multiplies load twelvefold. What helps most?

Headroom is relative to current load; a known burst is best met with capacity added in advance.

Which are process measures of deployability?

They measure how the team changes the system, not the running system or the code.

In a load test, what is the knee?

Past the knee, a saturated part makes requests queue; that's your real capacity.

10. Go deeper

Resource	Time	Why
DORA's software delivery metrics	15 min	The process measures for deployability, with definitions.
Service Level Objectives (Google SRE book)	30 min	How to turn "fast and reliable" into measured targets with percentiles.
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)	book	Measuring and governing characteristics, including structural measures.