From 4843eac12e6689006dab978b74825f09cf615d03 Mon Sep 17 00:00:00 2001
From: Claude AI <claude@thedevops.dev>
Date: Mon, 12 Jan 2026 10:36:27 +0000
Subject: [PATCH] docs: add scaling history documentation for demo-nginx

---
 apps/demo-nginx/docs/SCALING_HISTORY.md | 107 ++++++++++++++++++++++++
 1 file changed, 107 insertions(+)
 create mode 100644 apps/demo-nginx/docs/SCALING_HISTORY.md

diff --git a/apps/demo-nginx/docs/SCALING_HISTORY.md b/apps/demo-nginx/docs/SCALING_HISTORY.md
new file mode 100644
index 0000000..9d55faa
--- /dev/null
+++ b/apps/demo-nginx/docs/SCALING_HISTORY.md
@@ -0,0 +1,107 @@
+# 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