# Demo-Nginx Scaling History

This document tracks the scaling changes made to the demo-nginx deployment for capacity planning and audit purposes.

## Scaling Timeline

### 2026-01-12: Scale to 5 Replicas
**Change:** Increased from 3 to 5 replicas  
**Reason:** Enhanced capacity and improved high availability  
**Impact:**
- Additional 2 pod instances for better load distribution
- Improved resilience against node failures
- Better handling of traffic spikes
- Total resource allocation:
  - CPU requests: 500m (5 × 100m)
  - Memory requests: 640Mi (5 × 128Mi)
  - CPU limits: 1000m (5 × 200m)
  - Memory limits: 1280Mi (5 × 256Mi)

**Commit:** `0669ac66c8a651f74b4c16a4618db03bdd843c02`  
**Deployment Method:** GitOps via ArgoCD automatic sync

### 2026-01-12: Scale to 3 Replicas
**Change:** Increased from 2 to 3 replicas  
**Reason:** Initial scaling for improved availability  
**Commit:** `d5ffa97159ec391de950dc2d861361074ff3eee8`

### Initial Deployment: 2 Replicas
**Change:** Initial deployment with 2 replicas  
**Reason:** Baseline deployment for demo application

## Current Configuration

- **Replicas:** 5
- **Namespace:** demo-app
- **Image:** docker.io/vladcrypto/demo-nginx:main-50
- **Service Type:** ClusterIP
- **Port:** 80
- **Health Checks:** Liveness and Readiness probes enabled
- **Monitoring:** Prometheus scraping enabled

## Scaling Guidelines

### When to Scale Up
- CPU utilization consistently above 70%
- Memory utilization consistently above 75%
- Response time degradation observed
- Preparing for expected traffic increase
- Node maintenance requires pod redistribution

### When to Scale Down
- CPU utilization consistently below 30% for extended period
- Cost optimization requirements
- Application usage patterns indicate over-provisioning

## Resource Considerations

Each replica consumes:
- **CPU Request:** 100m
- **Memory Request:** 128Mi
- **CPU Limit:** 200m
- **Memory Limit:** 256Mi

Total cluster resources for 5 replicas:
- **Total CPU Requests:** 500m (0.5 cores)
- **Total Memory Requests:** 640Mi (~0.625 GB)
- **Total CPU Limits:** 1000m (1 core)
- **Total Memory Limits:** 1280Mi (~1.25 GB)

## Monitoring and Alerts

Monitor the following metrics in Grafana:
- Pod CPU/Memory utilization
- Request latency
- Error rates
- Pod restart count
- Service availability

## Rollback Procedure

If issues arise after scaling:

1. Revert the deployment.yaml in Git:
   ```bash
   git revert <commit-hash>
   git push
   ```

2. ArgoCD will automatically sync the change

3. Or manually scale via kubectl:
   ```bash
   kubectl scale deployment demo-nginx -n demo-app --replicas=<previous-count>
   ```

## Related Documentation

- [CICD_GUIDE.md](./CICD_GUIDE.md) - CI/CD pipeline documentation
- [ROLLBACK_MANUAL.md](./ROLLBACK_MANUAL.md) - Detailed rollback procedures
- [README.md](./README.md) - General application documentation

## Notes

- All scaling operations are tracked in Git for audit trail
- ArgoCD manages automatic synchronization from Git to cluster
- Changes follow GitOps principles for declarative infrastructure
- Scaling decisions should be data-driven based on monitoring metrics