The 99.95% Promise That the Architecture Cannot Keep
Fabrikam sells payroll software to 900 corporate customers under a contract guaranteeing 99.95% monthly availability, with service credits if it is missed. The service is a single-region Azure App Service deployment (published SLA 99.95%) that calls Azure SQL Database (published SLA 99.99%) synchronously on every single request, with no caching and no second region. Last quarter Fabrikam measured 99.96% and the CTO concluded 'we have headroom.' Separately, a customer's security team has sent a questionnaire asking who patches the App Service operating system, who patches the SQL engine, and who is responsible for encrypting the payroll database's data at rest.
1. Calculate the availability Fabrikam's design can actually deliver, and assess the CTO's conclusion.
Read the worked answer
Both components sit on the critical path of every request, so their SLAs multiply:
0.9995 × 0.9999 = 0.99940 → 99.94% composite.
In downtime terms over a 30-day month (43,200 minutes):
- The contract allows 0.05% ≈ 21.6 minutes.
- The architecture permits 0.06% ≈ 25.9 minutes.
Fabrikam promises more than its own design can guarantee. If App Service and SQL have bad months simultaneously - independent failures do overlap over time - Fabrikam owes credits even though both services met their published SLAs.
The CTO is wrong. The published SLA is a financial guarantee from Microsoft to Fabrikam, not a design target, and it says nothing about Fabrikam's own code, configuration errors, or bad deployments. One quarter at 99.96% is a single sample; it means failures did not coincide in those 90 days, not that capacity exists. The multiplication is the correct model here precisely because 100% of requests call SQL; if most requests were served from cache the naive product would be overly pessimistic.
2. What would a second region change about the numbers, and what would still be unprotected?
Read the worked answer
What improves: the compute and data tiers stop being serial dependencies. With active-active web tiers behind a global load balancer and a replicated database, a regional failure no longer necessarily takes the service down; the composite figure moves toward the SLA of the surviving path rather than the product of two failure-prone components. Note the front door itself becomes a new serial component and has its own SLA, so nothing becomes 100%.
What does not improve:
- Fabrikam's own code and deployments still count as downtime. The SLA does not cover a bad release, and multi-region makes bad releases faster to spread.
- Split-brain and data loss. Payroll data replicated asynchronously means a failover can lose the last few transactions - a correctness breach, not just an availability one, and potentially worse than the outage.
- Cost and complexity rise materially, so this is only justified if service credits plus churn exceed it.
The cheap first move is usually to remove the synchronous dependency (cache, queue, retry with backoff) before buying a second region.
3. Answer the security questionnaire: who patches the OS, who patches SQL, and who is responsible for encrypting the data at rest?
Read the worked answer
This is a PaaS deployment, so responsibility is split, not transferred.
| Item | Responsible |
|---|---|
| App Service guest OS and its patches | Microsoft |
| SQL Database engine, patching, and the physical hosts | Microsoft |
| Encryption of data at rest at the platform layer | Microsoft (applied by default to Azure Storage and Azure SQL) |
| Key management if customer-managed keys are used | Fabrikam (Key Vault, rotation, access to the key) |
| Classifying payroll data and deciding what may be stored where | Fabrikam |
| Identity, access control, firewall rules, private endpoints | Fabrikam |
| Application code, configuration, and its vulnerabilities | Fabrikam |
The trap is answering 'Microsoft encrypts it, so Microsoft owns it.' Encryption at rest is a platform capability Microsoft operates; the customer still owns the obligations the regulator cares about - data classification, least-privilege access, key custody, and audit. Always in cloud, the customer always retains accountability for data, identities, and endpoints.