Q4: Answer

q4-scalability/calculations.md

@@ -0,0 +1,25 @@
+# Scalability & Load Balancing Design
+
+## 2. Capacity Planning (Container Calculation)
+
+To handle 15,000 req/s efficiently with a safety buffer to prevent server overload during spikes:
+
+- **Base Requirement:** 15,000 req/s ÷ 500 req/s per container = **30 Containers**.
+- **Safety Buffer (30%):** 30 × 0.30 = **9 Containers**.
+- **Total Required Containers:** 30 + 9 = **39 Containers**.
+
+## 3. Cold Start Strategy
+
+To minimize the "Cold Start" delay when new containers are provisioning under sudden load, we will implement two main solutions:
+
+1.  **Pre-baked Images:** Instead of downloading heavy dependencies at runtime, we install and package all core dependencies directly into the Docker image during the build stage. This ensures the container has everything it needs and starts up instantly.
+2.  **Proactive Auto-scaling (Early Alarms):** Configure the autoscaler to trigger at an earlier threshold (e.g., 75%-85% utilization). This provides a time buffer, giving new containers enough time to start and become fully ready before the existing containers hit their absolute limits and crash.
+
+## 4. Stateful Workloads & Ghaymah Block Storage
+
+Containers are "Stateless" by nature, meaning if a container restarts or dies, all its internal data is permanently lost. For "Stateful" applications like databases, this behavior is unacceptable.
+To solve this, we use **Ghaymah Block Storage** (which acts exactly like Docker Volumes):
+
+- We create an independent, external Block Storage disk.
+- We mount this disk directly to the database container.
+- All data is written to this external volume. If the database container crashes, the Block Storage remains safe and intact. When a new container spins up, it simply reconnects to the same volume, ensuring zero data loss and maintaining the state.