Quality Attributes: Latency, Availability, Durability and Scalability

Most non-functional requirements constrain one of four qualities: latency, availability, durability or scalability. Naming the quality a requirement is about tells you which part of the design has to answer it, and which measurement will prove it is met.

Durability is not availability. Both sound like "not losing things", and they fail in different ways. A system can be unavailable and durable: the database server is down for an hour, nobody can order, and when it returns every order is still there. A system can be available and not durable: it answers every request, but keeps orders only in a server's memory, so a restart loses them. The first needs spare copies of the running parts; the second needs data written to disk, and copied, before the system says "saved".

Each quality turns into a number. Latency is measured in milliseconds at a percentile, such as "95% of requests under 200 ms". Availability is a percentage of time, such as 99.9%. Durability is stated as data you may lose, often "none" once a write is confirmed. Scalability is stated as a load, such as 5,000 requests a second, that the system must reach by adding machines.

Other names you will meet. Throughput is the number of requests handled each second, the partner of latency. Consistency is whether every reader sees the latest write. Both turn up in requirements too, and both are measured the same way: with a number someone can check.

So when you read a requirement, name its quality first: the name decides which part of the design must answer it.