Waarvoor we ontwerpen
Niet-functionele vereisten bepalen de kwaliteit van een systeem, los van de functionaliteit. Architectuurbeslissingen hebben een rechtstreekse impact op deze attributen.
| Attribuut | Beschrijving | Architecturale aandachtspunten |
|---|---|---|
| Performantie | Responstijd, doorvoer, latentie | Caching, CDN, asynchrone verwerking, databaseoptimalisatie |
| Schaalbaarheid | Groeiende workload aankunnen | Stateless ontwerp, horizontale schaling, load balancing |
| Beschikbaarheid | Uptime, fouttolerantie | Redundantie, health checks, auto-healing, multi-region |
| Betrouwbaarheid | Consistent, voorspelbaar gedrag | Retrybeleid, circuit breakers, graceful degradation |
| Beveiliging | Bescherming tegen bedreigingen | Authenticatie, autorisatie, versleuteling, auditlogging |
| Onderhoudbaarheid | Hoe eenvoudig het systeem aan te passen is | Losse koppeling, documentatie, clean code, geautomatiseerde tests |
| Observability | Systeemgedrag begrijpen | Logging, metrics, distributed tracing, alerting |
Beschikbaarheid in cijfers
Elke extra negen kost geld, dus spreken we eerst het doel af met de business en ontwerpen we daarna de redundantie die erbij past.
Wat een doel echt betekent
Beschikbaarheidsdoel
Toegestane downtime
Per jaar3d 15u
Per maand7u 18m
Per week1u 40m
Samengestelde beschikbaarheid van één workload
App Service 99.95%Azure SQL 99.99%Service Bus 99.9%
Verwachte beschikbaarheid
99.84%
≈ 14u downtime per jaar
Illustratief voorbeeld