Quality Attributes in System Design

Availability measures whether a system is operational and accessible. A commonly used calculation is uptime divided by total observed time. A 99.9% monthly availability target allows approximately 0.1% downtime. For a 30-day month, that is about 43.2 minutes. Availability planning therefore needs to consider instance failures, health checks, database availability, deployment procedures and recovery processes—not just whether an application process is running.

Performance describes how quickly the system responds. Latency percentiles are more informative than an average alone because averages can conceal slow tail requests. The supplied quality-attributes notes use p50 = 80 ms, p95 = 180 ms and p99 = 450 ms as an illustrative example. Throughput measures completed work over time; for APIs it is often expressed as requests per second. CPU, memory and database latency help explain where time is spent.

Reliability means the system performs its intended function correctly and consistently. If an API returns 201 Created for a task, the task should actually have been persisted. Durability means successfully persisted data survives failures. Reliability spans the end-to-end operation; durability is particularly concerned with the persistence layer and recovery guarantees. A successful response before a safe commit can violate both expectations.

Scalability is the ability to handle increasing workload by adding resources. Vertical scaling increases the capacity of one machine; horizontal scaling adds instances. Horizontal scaling generally needs stateless application instances or shared state so any instance can handle a request. Fault tolerance is the ability to continue operating when components fail. Multiple application instances can improve tolerance to an individual instance failure, but they do not by themselves make the database or every dependency fault tolerant.

Security protects accounts, credentials, authorisation boundaries, APIs and sensitive data. Consistency describes what values clients observe after operations, especially when related data changes. Maintainability measures how easily engineers can understand, modify, test and operate the system. These attributes should be supported by explicit design: password hashing, encrypted transport, backend authorisation, transactions, clear modules, tests, configuration management and migration practices.

Observability allows engineers to understand what is happening inside a running system. The three major pillars are logs, metrics and traces. Metrics show aggregate behaviour such as request count, latency and error rate. Logs provide event context. Distributed traces connect work across application and dependency boundaries, helping identify where a request spends time or fails. Contextual identifiers are useful, but logs must not expose tokens, passwords or secrets.

The supplied requirements identify a 99.9% monthly availability target, p50 latency below 100 ms, p95 below 200 ms, p99 below 500 ms, and an approximate peak throughput target of 500 RPS. These are planning targets, not verified production measurements. Performance tests should state the workload, data volume, deployment shape and observation window used to evaluate them.