What I design for
Non-functional requirements define system quality beyond features. Architectural decisions directly impact these attributes.
| Attribute | Description | Architecture considerations |
|---|---|---|
| Performance | Response time, throughput, latency | Caching, CDN, async processing, database optimization |
| Scalability | Handle growing workload | Stateless design, horizontal scaling, load balancing |
| Availability | Uptime, fault tolerance | Redundancy, health checks, auto-healing, multi-region |
| Reliability | Consistent, predictable behavior | Retry policies, circuit breakers, graceful degradation |
| Security | Protection from threats | Authentication, authorization, encryption, audit logging |
| Maintainability | Ease of modification | Loose coupling, documentation, clean code, automated tests |
| Observability | Understand system behavior | Logging, metrics, distributed tracing, alerting |
Availability in numbers
Every extra nine costs money, so I agree the target with the business first and then design the redundancy to match.
What a target really means
Availability target
Allowed downtime
Per year3d 15h
Per month7h 18m
Per week1h 40m
Composite availability of one workload
App Service 99.95%Azure SQL 99.99%Service Bus 99.9%
Expected availability
99.84%
≈ 14h of downtime per year
Illustrative example