first commit

q4-scalability/calculations.md

@@ -0,0 +1,41 @@
+# Scalability and Load Balancing
+
+## 2. Calculating the Number of Containers Required
+
+**Given:**
+- Total load: 15,000 req/s
+- Capacity per container: 500 req/s
+- Safety margin: 30%
+
+**Calculation:**
+
+```
+Effective load = 15,000 × 1.3 = 19,500 req/s
+Number of containers = 19,500 ÷ 500 = 39 containers
+```
+
+**Result: 39 containers**
+
+Check: 15,000 ÷ 39 ≈ 385 req/s per container (≈ 77% of max capacity), leaving a ~23% margin to absorb sudden spikes in load.
+
+---
+
+## 3. Cold Start Strategy for New Containers
+
+| Strategy | Description |
+|---|---|
+| **Predictive Scaling** | Monitor the load growth trend and spin up new containers before the critical threshold is reached |
+| **Warm Pool** | Keep 2-3 containers ready in standby mode so they can be activated instantly when needed |
+| **Golden Images** | Use pre-baked, optimized container images to reduce init time |
+| **Gradual Traffic Ramp-up** | Route traffic to the new container gradually instead of sending full load immediately |
+| **Readiness Probe** | Don't add the container to the load balancer until it passes a readiness check |
+
+---
+
+## 4. Using ghaymah Block Storage for Stateful Workloads
+
+- **Persistence across rescheduling:** If a container fails or is moved to another node, the same volume can be reattached without losing data.
+- **Decoupling storage from compute:** Allows the container layer to scale independently from the storage layer.
+- **Low-latency I/O:** Suitable for databases and queueing systems that need fast read/write.
+- **Snapshots:** Periodic snapshots for backup and data recovery in case of failures.
+- **Single-container attachment:** Typically used behind a centralized database rather than inside each of the 39 containers, to preserve statelessness in the processing layer.