Uptime Targets
Availability Percentages
Availability | Downtime/Year | Downtime/Month | Use Case
─────────────|───────────────|────────────────|──────────────
99% | 3.65 days | 7.2 hours | Non-critical
99.9% | 8.76 hours | 43.8 minutes | Standard
99.99% | 52.6 minutes | 4.38 minutes | Critical
99.999% | 5.26 minutes | 26.3 seconds | Mission critical
Calculation Formula
Availability = (Total Time - Downtime) / Total Time × 100
Example:
- Total time: 365 days = 8760 hours
- Downtime: 4 hours
- Availability: (8760 - 4) / 8760 × 100 = 99.954%
Nines Calculation:
- 99.9% = 8.76 hours/year downtime
- 99.99% = 52.6 minutes/year downtime
- 99.999% = 5.26 minutes/year downtime
Magento Availability Targets
Component | Target | Rationale
─────────────────|───────────|────────────────────
Web application | 99.9% | Revenue-critical
API endpoints | 99.95% | Integration-critical
Admin panel | 99% | Internal use
Search | 99.9% | Customer experience
Checkout | 99.99% | Direct revenue impact
SLA Definition
SLA Structure
SLA Component:
- Availability percentage
- Performance metrics (response time)
- Support response time
- Incident notification time
- Compensation for breaches
Magento SLA Example
service_level_agreement:
availability:
target: 99.9%
measurement_period: monthly
excluded: scheduled_maintenance
performance:
response_time_p95: 500ms
response_time_p99: 1000ms
throughput: 1000_rps
support:
critical_incident: 15_minutes
high_priority: 1_hour
medium_priority: 4_hours
low_priority: 24_hours
notification:
status_page: status.example.com
email_alerts: ops@example.com
slack_alerts: '#incidents'
SLA Monitoring
# Track SLA compliance
# Monthly availability calculation
downtime_minutes=$(cat downtime.log | wc -l)
total_minutes=43200 # 30 days
availability=$(echo "scale=4; ($total_minutes - $downtime_minutes) / $total_minutes * 100" | bc)
echo "Availability: ${availability}%"
# Alert if below target
if (( $(echo "$availability < 99.9" | bc -l) )); then
echo "SLA BREACH: Availability below 99.9%"
fi
Redundancy Requirements
Redundancy Levels
Level 1: Single server (no redundancy)
Level 2: Active-Passive (failover)
Level 3: Active-Active (load sharing)
Level 4: Multi-region (geographic)
Component Redundancy
Component | Minimum | Recommended | Critical
─────────────────|────────────|─────────────|──────────
Web nodes | 2 | 3+ | 4+
Database | 1+1 replica| 1+2 replicas| 1+3 replicas
Redis | 3 nodes | 6 nodes | 9 nodes
Varnish | 2 nodes | 3+ nodes | 4+ nodes
Load balancer | 2 nodes | 2+ nodes | 3+ nodes
OpenSearch | 3 nodes | 5+ nodes | 7+ nodes
No Single Point of Failure
SPoF Check:
- Web server: Remove one → Still works? ✓
- Database primary: Remove one → Still works? ✗
- Redis primary: Remove one → Still works? ✗
- Load balancer: Remove one → Still works? ✗
Every component needs redundancy for high availability
Availability Monitoring
Health Check Configuration
// Health check endpoint
// pub/health_check.php
header('Content-Type: application/json');
$checks = [
'database' => $this->checkDatabase(),
'redis' => $this->checkRedis(),
'opensearch' => $this->checkSearch(),
'filesystem' => $this->checkFilesystem()
];
$healthy = !in_array(false, $checks);
http_response_code($healthy ? 200 : 503);
echo json_encode([
'status' => $healthy ? 'healthy' : 'unhealthy',
'checks' => $checks,
'timestamp' => time()
]);
Uptime Monitoring
# External uptime check (every 60 seconds)
curl -f http://store.example.com/health_check.php || alert
# Response time check
time=$(curl -o /dev/null -s -w '%{time_total}' http://store.example.com/)
if (( $(echo "$time > 2.0" | bc -l) )); then
echo "ALERT: Response time ${time}s exceeds 2s threshold"
fi
Availability Dashboard
Dashboard Metrics:
- Current uptime percentage
- Downtime incidents this month
- Mean time between failures (MTBF)
- Mean time to recovery (MTTR)
- SLA compliance status
- Component health status
Quiz
1. How much downtime does 99.9% availability allow per year?
2. What is the SLA target for checkout availability?
3. What is a single point of failure (SPoF)?
Flashcards
Question
99.9% availability downtime?
Click to reveal answer
Answer
8.76 hours per year or 43.8 minutes per month
Question
SPoF?
Click to reveal answer
Answer
Single Point of Failure: component whose failure stops the system
Question
Checkout availability target?
Click to reveal answer
Answer
99.99% (52.6 minutes downtime per year)
Question
Redundancy levels?
Click to reveal answer
Answer
Single → Active-Passive → Active-Active → Multi-region
Revision Notes
Key Takeaways
- 1. 99.9% availability = 8.76 hours downtime/year
- 2. Checkout requires 99.99% availability (52.6 min/year)
- 3. Every component needs redundancy to eliminate SPoFs
- 4. Monitor health checks and track SLA compliance
- 5. Define SLA with availability, performance, and support targets
Interview Tips
- • Calculate availability percentages and downtime budgets
- • Explain SLA components and how to monitor compliance
- • Identify and eliminate single points of failure
Cheat Sheet
Availability:
99.9% = 8.76h/year
99.99% = 52.6min/year
99.999% = 5.26min/year
SLA Components:
Availability target
Performance metrics
Support response time
Incident notification
Redundancy:
Minimum: 2 of each component
Eliminate all SPoFs
Active-Active for critical
Monitoring:
Health checks every 60s
Track MTBF and MTTR